Python 3.15: features that didn't make the headlines

From this example:

    lazy from typing import Iterator

    def stream_events(...) -> Iterator[str]:
        while True:
            yield blocking_get_event(...)

    events = stream_events(...)

    for event in events:
        consume(event)

Do we finally have "lazy imports" in Python? I think I missed this change. Is this also something from Python 3.15 or earlier?

Note that 3.15 is not released yet. It will come out in 4 months

It's nice that python 3.15 added Iterator synchronization primitives: https://docs.python.org/3.15/library/threading.html#iterator.... These will nicely complement my threaded-generator package which is doing just this but using a thread/process+generator+queue: https://pypi.org/project/threaded-generator/

> Iterators, async functions and async iterators don't work well here because they have different semantics to standard functions. When you call them they return immediately with a generator object, coroutine function and async generator object respectively. So the decorator completes immediately as opposed to the entire lifecycle what it's wrapping.

> This is an unfortunate problem I've encountered many times, and it's often a problem for normal decorators too. But this has changed in 3.15, now the ContextDecorator will check the type of the function it's wrapping and ensure that the decorator covers the entire lifespan.

I very much like the idea of that change - but it also seems kind of dangerous, to do this with no "opt-in mechanism", as that quite subtly changes the behavior of existing usage sites.

This is a bit of a "spacebar heating" situation, because someone would have to intentionally use a decorator in the old, broken way, but if someone actually did that, things may unexpectedly break.

> I've left this one to the bonus section because I've never used set operations on Counters and I'm finding it extremely hard to think of a use case for xor specifically. But I do appreciate the devs adding it for completeness.

Check out symmetric difference

https://en.wikipedia.org/wiki/Symmetric_difference

There's a good interview about Python internals and management, particularly in relation to free-threading: https://alexalejandre.com/programming/interview-with-ngoldba...

Oh, my beloved Python, for nearly 15 years I wrote you. I miss you, but I no longer do — it's not your fault, life has changed.

I was so into Python for 10 years, was enjoyable to work in. But have deleted 100k+ lines this year already moving them to faster languages in a post AI codebot world. Mostly moving to go these days.

One of the Counter examples is incorrect, tested on both 3.13 and 3.15.0a

  >>> from collections import Counter 
  >>> c = Counter(a=3, b=1)  
  >>> d = Counter(a=1, b=2)   
  >>> c-d  
  Counter({'a': 2})

I come to Python around version 1.5, painfully tired by debugging CGI scripts, created by wannabe perl-golfers. Unfortunately, I feel like Python is losing more and more of the zen that once tempted me...

Lazy loading looks like a last nail in the coffin, where my love to Python was buried, although it was a long, tiresome process.

Thread safe ittertors? really are we still on these topics

lazy from typing import Iterator

def stream_events(...) -> Iterator[str]: while True: yield blocking_get_event(...)

events = stream_events(...)

for event in events: consume(event)

I am not a python dev but have the utmost respect for the ecosystem.

But damn, with all the supply chain attacks now in the news, could they just make a simple way (for non python insiders) to install python apps without fearing to be infected by a vermin with full access to my $HOME ...

funny how we may have to wait even longer for llms to pick up this update in their pre-training

From this example:

    lazy from typing import Iterator

    def stream_events(...) -> Iterator[str]:
        while True:
            yield blocking_get_event(...)

    events = stream_events(...)

    for event in events:
        consume(event)

Do we finally have "lazy imports" in Python? I think I missed this change. Is this also something from Python 3.15 or earlier?

What benefit does the lazy import have here - if we use the value in a type hint at module scope anyway? Would that require Deferred evaluation of annotations -- which I don't think are enabled by default?

Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions

Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports (1% of which are probably Shai Hulud now).

And now even type imports are apparently so slow that you have to disable them if unused during the normal untyped execution.

If Instagram or others wants a professional language, they should switch to Go or PHP instead of shoehorning strange features into a language that wasn't built for their use cases.

There's a good interview about Python internals and management, particularly in relation to free-threading: https://alexalejandre.com/programming/interview-with-ngoldba...

Oh, my beloved Python, for nearly 15 years I wrote you. I miss you, but I no longer do — it's not your fault, life has changed.

I was so into Python for 10 years, was enjoyable to work in. But have deleted 100k+ lines this year already moving them to faster languages in a post AI codebot world. Mostly moving to go these days.

This is straightforward in the first instance, but how do you see maintenance of those projects going forward - especially adding more complex features ?

I can see one way forward being to prototype them in python and convert.

I'm still on the lookout for a comprehensive Django-like web framework for go. That would be an instant hit for me.

Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?

Go is terrible for scientific/ML work though, the libraries just aren't there. The wrapping C API story is weak too even with LLMs to assist.

Try and write a signal processing thing with filters, windowing, overlap, etc. - there's no easy way to do it at all with the libraries that exist.

i don’t really see it this way. the value of a token in Python is much higher than it is in lower-level language

Thats very intersting, If I may ask was it from professional projects or personal projects?

Same, I’m not sure how Python survives this outside of machine learning.

All of our services we were our are significantly faster and more reliable. We used Rust, it wasn’t hard to do

Three things I find unlikely about this:

- You wrote 100K lines of code (I've worked on several large C++ projects that were far smaller)

- You wrote those lines in Python (surely the whole point of Python is to write less code)

- You deleted them (never delete anything, isn't this what modern VCS is all about?)

But whatever floats your boat.

Note that 3.15 is not released yet. It will come out in 4 months

funny how we may have to wait even longer for llms to pick up this update in their pre-training

Is there seriously no solution to this? Perhaps something we fan do post training? For example add the new features to SKILLS.md? But the trade-off here is of course tokens.

Check out symmetric difference

https://en.wikipedia.org/wiki/Symmetric_difference

Type annotations are lazily evaluated by moving them behind a special annotations scope as of 3.14:

https://peps.python.org/pep-0649/

https://docs.python.org/3/reference/compound_stmts.html#anno...

With 3.15, using lazy typing imports is more or less an alternative to putting such imports behind an "if TYPE_CHECKING" guard.

Yeah, but applied to counters it would be the symmetric difference between multisets, which doesn't have a natural definition. If I understood the proposal they'd be defining it as absolute value of the difference of the counts, which isn't even associative.

If they only considered parities it could be interpreted as addition in F_2, which is more natural, but I'd still agree that it's hard to see how you'd use something like this in practice.

This is straightforward in the first instance, but how do you see maintenance of those projects going forward - especially adding more complex features ?

I can see one way forward being to prototype them in python and convert.

I very much like the idea of that change - but it also seems kind of dangerous, to do this with no "opt-in mechanism", as that quite subtly changes the behavior of existing usage sites.

This is a bit of a "spacebar heating" situation, because someone would have to intentionally use a decorator in the old, broken way, but if someone actually did that, things may unexpectedly break.

The Python core team seems to think it's unlikely that anyone's relying on the existing behavior: https://github.com/python/cpython/pull/136212#issuecomment-4...

Eh, what's the worst that could happen? Developers opting to run an old version of Python due to incompatible changes? I can't see that happening.

Go is terrible for scientific/ML work though, the libraries just aren't there. The wrapping C API story is weak too even with LLMs to assist.

Try and write a signal processing thing with filters, windowing, overlap, etc. - there's no easy way to do it at all with the libraries that exist.

I think the purpose of go is to write CRUD. Stray from that and you're on your own.

Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?

Programs have to run in a lot of different contexts, not just as servers, and for some of those contexts (especially say glueing together other programs), an interpreted language is more convenient and easier to work with. In fact, unless I care about performance, I'm going to use an interpreted language because having the source close at hand when something breaks just turns out to be super useful.

Because it's quick and easy to radically alter and refactor your prototype as you learn the problem space. By the time it works you often find out that you don't need anything more. This is something that Perl had.

Once your program starts to get bigger you have abstractions that can cope fairly well and keep your code simple to use - this is what Perl didn't have.

If you need more speed then you can write extensions in some compiled language.I think TCL was better at this hybrid approach but Python is a nicer language in itself.

You can also just dump python and write everything in that other language but now you understand the problem space quite well and you won't be trying to learn about it using a language where change is "difficult."

IMO the main reasons people use Python are:

1. The very first steps are quite simple. Hello world is literally just `print("hello world")`. In other languages it can be a lot more complex.

2. It got a reputation as a beginner-friendly language as a result.

3. It has a "REPL" which means you can type code into a prompt and it will execute it interactively. This is very helpful for research (think AI) where you're trying stuff out and want to plot graphs and so on.

IMO it is undeservedly popular, or at least was. Wind back 10 years to when it was rapidly gaining mindshare:

1. While "hello world" is simple, if you went further to more complex programs you would hit two roadblocks: a) the lack of static type checking means large programs are difficult to maintain, and b) it's really really slow.

2. While the language is reasonable, the tooling (how you install packages, manage the code and so on) was eye-bleedingly abysmal.

3. While the REPL did technically exist, it was really bare bones. It couldn't even handle things like pasting code into it if the code contained blank lines (which it usually does).

However since it has become arguably the most popular language in the world, a lot of people have been forced to use it and so it is actually getting quite decent now. It has decent static types (even if lots of people still don't use them), the REPL is actually decent now (this changed very recently), and there's a new third party tool called `uv` to manage your code that is actually good.

The biggest issue with it now is that it's still horrifically slow (around 50-200x slower than "fast" languages like C++, Rust etc). It is pretty unlikely that that will ever change. People always try to excuse this by saying Python is a "glue" language and you just use it to connect components written in faster languages, but a) that's pure "you're holding it wrong", and b) that only works in some cases where there are nicely separated "slow bits" that can be moved to another language. That's the case for AI for example, where it's all numerical, but for lots of things it isn't. Mercurial was a competitor to Git that was written in Python and lost partly because it was way too slow. They've started writing parts in Rust but it took them 10 years to even start doing that and by then it was far too late.

> what would you suggest?

It really depends on what you want to make. I would pick something to make first and then pick the language based on that. Something like:

* AI: Python for sure. Make sure you use uv and Pyright.

* Web-based games: Typescript

* Web sites: Typescript, or maybe Go.

* Desktop GUI: Tbh I'd still use C++ with QtWidgets. Getting a bit old-school now tbf.

Also Rust is the best language of them all, but I dunno if I'd pick it as a beginner unless you really know you want to get into programming.

Thread safe ittertors? really are we still on these topics

lazy from typing import Iterator

def stream_events(...) -> Iterator[str]: while True: yield blocking_get_event(...)

events = stream_events(...)

for event in events: consume(event)

Lazy loading looks like a last nail in the coffin, where my love to Python was buried, although it was a long, tiresome process.

One of the Counter examples is incorrect, tested on both 3.13 and 3.15.0a

  >>> from collections import Counter 
  >>> c = Counter(a=3, b=1)  
  >>> d = Counter(a=1, b=2)   
  >>> c-d  
  Counter({'a': 2})

Is there seriously no solution to this? Perhaps something we fan do post training? For example add the new features to SKILLS.md? But the trade-off here is of course tokens.

I am not a python dev but have the utmost respect for the ecosystem.

There is no security barrier at all in UNIX(-like) Os's between a caller/callee, this is not thing that python can just fix.

There are ways to harden and/or reduce privileges, but shells/scripting languages will always have this issue on any modern OS.

The UNIX way to help prevent that is really to run processes as another user, but people seem to refuse to do so. You should always expect any process running as your UID to be able to access any data owned or visible to your UID.

While it is possible to reduce the risk of disclosure, they are all wack-a-mole preventions protecting the low hanging fruit, not absolute guarantees.

That is purely due to how UNIX works [0]

[0] https://man7.org/linux/man-pages/man7/credentials.7.html

There is little that they can do short of running the programs in a VM. Linux distros aren't engineered to consider applications as something different from the user running them. You need a completely different security model to achieve that and the Python runtime isn't tackle that.

Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions

Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports (1% of which are probably Shai Hulud now).

And now even type imports are apparently so slow that you have to disable them if unused during the normal untyped execution.

If Instagram or others wants a professional language, they should switch to Go or PHP instead of shoehorning strange features into a language that wasn't built for their use cases.

If they only considered parities it could be interpreted as addition in F_2, which is more natural, but I'd still agree that it's hard to see how you'd use something like this in practice.

Once your program starts to get bigger you have abstractions that can cope fairly well and keep your code simple to use - this is what Perl didn't have.

If you need more speed then you can write extensions in some compiled language.I think TCL was better at this hybrid approach but Python is a nicer language in itself.

Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for years

> Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports

Just because you don’t like a feature doesn’t mean it’s because of AI and bad code.

Empirically, I have used the current accepted way to do lazy imports (import statement inside a function) before AI coding was even a mainstream thing, for personal code that sometimes needs a heavy import and sometimes doesn’t.

The lazy statement would be an improvement as it allows one to see all the imports at the top where you expect them to be.

On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.

> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent

Oh, that is such a nice thing.

Type annotations are lazily evaluated by moving them behind a special annotations scope as of 3.14:

https://peps.python.org/pep-0649/

https://docs.python.org/3/reference/compound_stmts.html#anno...

With 3.15, using lazy typing imports is more or less an alternative to putting such imports behind an "if TYPE_CHECKING" guard.

Ah, thanks for the update. My only check before asking was to check if the future feature for annotations had been enabled by default yet. It has then effectively been abandoned instead, I guess.

The Python core team seems to think it's unlikely that anyone's relying on the existing behavior: https://github.com/python/cpython/pull/136212#issuecomment-4...

Eh, what's the worst that could happen? Developers opting to run an old version of Python due to incompatible changes? I can't see that happening.

I think the purpose of go is to write CRUD. Stray from that and you're on your own.

Thats very intersting, If I may ask was it from professional projects or personal projects?

i don’t really see it this way. the value of a token in Python is much higher than it is in lower-level language

There is no security barrier at all in UNIX(-like) Os's between a caller/callee, this is not thing that python can just fix.

There are ways to harden and/or reduce privileges, but shells/scripting languages will always have this issue on any modern OS.

While it is possible to reduce the risk of disclosure, they are all wack-a-mole preventions protecting the low hanging fruit, not absolute guarantees.

That is purely due to how UNIX works [0]

[0] https://man7.org/linux/man-pages/man7/credentials.7.html

Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for years

Ok, good to see that they checked that possibility. Looks like there was no situation in which the previous behavior could have been usable, so yeah, agreeing with the change then.

crud is a pretty poor fit for go, you're better served by languages like python that can autogenerate classes that reflect the db schema. go's sweet spot is things like network servers.

I'm still on the lookout for a comprehensive Django-like web framework for go. That would be an instant hit for me.

Try another language? The Go ecosystem tends towards libraries as opposed to "frameworks."

I personally chose C# for this reason, because ASP.NET is mature and (IMO) well designed. But there's also Java/Spring and and lots of other options in different languages depending on your preferences.

Same here. Django is my last holdout for Python. Everything new is go.

Same, I’m not sure how Python survives this outside of machine learning.

All of our services we were our are significantly faster and more reliable. We used Rust, it wasn’t hard to do

the funny thing is that everyone, including myself, posited that python would be the winner of the ai coding wars, because of how much training data there is for it. My experience has been the opposite.

You can test on the device directly, without needing to recompile to try something.

Three things I find unlikely about this:

- You wrote 100K lines of code (I've worked on several large C++ projects that were far smaller)

- You wrote those lines in Python (surely the whole point of Python is to write less code)

- You deleted them (never delete anything, isn't this what modern VCS is all about?)

But whatever floats your boat.

> You deleted them (never delete anything, isn't this what modern VCS is all about?)

The person said: "deleted 100k+ lines this year already moving them to faster languages"

Are you saying that when you move code to another language/rewrite in another language, you leave the original languages code in your repo?

They didn't say they deleted it from their git history. I delete code all the time (doesn't mean its "gone", just that its not in my git head).

100k lines is tiny what are you on about, especially in the monolithic app sass world where many Fyll stack apps that handle all business ops are probably written with Django.

Our entire business runs on 300k lines of Ruby (on Rails) and I can keep most of the business logic in my head. I would say our codebase is not exactly “tiny” and just cracking the ceiling into “smal” territory. And comparatively, people probably write even less code in equivalent rails apps to django ones. 100k lines of C++ is miniscule.

Obviously “deleting code” in this context doesn’t mean purging version control history but the current state of the codebase.

Uhm what? All of those things are totally ordinary.

In its inception 35 years ago the creator of python could not foresee how far python would go and how the environment would look like today. But nowadays there are a lot of security mechanisms they could leverage to adapt (from chroot by default to namespaces, cgroup, etc. on Linux, pledge, unveil on OpenBSD).

The very idea that you offer a (python) package installer that is gonna pull a tree of code published and updated by random people in an unvetted manner open the door to all the supply chain attacks we are seeing.

Around the same time (early 90s) Java was designed with high isolation in mind but the goal and vision was very different. And Java had its own problems.

I'm saying that because at some point the security problem is gonna really hurt the python ecosystem.

> Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports

Just because you don’t like a feature doesn’t mean it’s because of AI and bad code.

I think this is just a natural consequence of an easy-to-use package system. The exact same story as with node. If you don't want lots of imports, don't make it so damn easy to pile them into projects. I'm frankly surprised we still see so few supply chain attacks, even though they picked up their cadence dramatically.

Too much syntactic sugar causes cancer of the semicolon.

True, but this is yet another code path that isn't exercised until specific conditions happen. That means even more latent application behaviour can go undetected by unit testing and security profiling until the moon is in the right phase, which is a boon for submarine attacks.

The lazy statement would be an improvement as it allows one to see all the imports at the top where you expect them to be.

As a now deleted comment pointed out, lazy imports had been requested forever. They were rejected forever and were accepted just when BigCorps wanted them.

Python-dev now is paid to shore up the failed Instagram stack.

IMO the main reasons people use Python are:

1. The very first steps are quite simple. Hello world is literally just `print("hello world")`. In other languages it can be a lot more complex.

2. It got a reputation as a beginner-friendly language as a result.

IMO it is undeservedly popular, or at least was. Wind back 10 years to when it was rapidly gaining mindshare:

2. While the language is reasonable, the tooling (how you install packages, manage the code and so on) was eye-bleedingly abysmal.

3. While the REPL did technically exist, it was really bare bones. It couldn't even handle things like pasting code into it if the code contained blank lines (which it usually does).

> what would you suggest?

It really depends on what you want to make. I would pick something to make first and then pick the language based on that. Something like:

* AI: Python for sure. Make sure you use uv and Pyright.

* Web-based games: Typescript

* Web sites: Typescript, or maybe Go.

* Desktop GUI: Tbh I'd still use C++ with QtWidgets. Getting a bit old-school now tbf.

Also Rust is the best language of them all, but I dunno if I'd pick it as a beginner unless you really know you want to get into programming.

Ok, good to see that they checked that possibility. Looks like there was no situation in which the previous behavior could have been usable, so yeah, agreeing with the change then.

Ah, thanks for the update. My only check before asking was to check if the future feature for annotations had been enabled by default yet. It has then effectively been abandoned instead, I guess.

Yup, "from __future__ import annotations" will eventually be removed:

> from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.

Oh, that is such a nice thing.

It's unrelated to the lazy keyword. Instead it's another feature related to error messages.

The example:

  >> 'hello'.toUpperCase()
  Traceback (most recent call last):
  ...
  AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?

Now I'm wishing for a single cross-language library, that I can somehow inject into every compiler/runtime/checker to get this, but with a single source of truth and across a wide range of languages. I hit this damn issue all the time, writing code in one language for another, would truly be a bliss to have that problem solved once and for all.

I think "Python is slow" is reductive and frankly just as useful as saying "Python begins with a 'P'". The story is more complicated than simply speed of execution.

Choosing a language is a game of trade-offs: potentially slower execution in return for faster development time, for example. If your team is already familiar with Ruby, will asking them to write a project in Rust necessarily result in a better product? Maybe, but it will almost certainly take much longer.

Anyway, how many Python programs are actually "too slow"? Most of the time, Python is fast enough, even if heavy computation is offloaded to other languages.

As for Rust being the best language of them all, that's, like, your opinion, man.

ptpython has existed for a decade, maybe two, and python is high level, more readable than most languages. Exec speed hasn’t mattered in my near thirty years of using it for business and prototyping tasks which it promoted early.

Yes it strains at the big to huge project end, not recommended to take it there. Still there are better tools to help now.

> * Web sites: Typescript, or maybe Go.

lol, no. Just no. Python is far superior for website backends unless perhaps you're running one of the top 20 websites in the world.

crud is a pretty poor fit for go, you're better served by languages like python that can autogenerate classes that reflect the db schema. go's sweet spot is things like network servers.

On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.

Try another language? The Go ecosystem tends towards libraries as opposed to "frameworks."

Same here. Django is my last holdout for Python. Everything new is go.

you just need the right tools https://github.com/CaliLuke/loom

Too much syntactic sugar causes cancer of the semicolon.

This seems a lot more due to an import running arbitrary code because stuff can happen in the top-level of a module rather than only happening in functions. From what I can tell, it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones, which tend to have a main function that everything else happens inside transitively. I guess this makes it easy if what you're writing is something that runs with no dependencies, but it's a pretty terrible experience as soon as you try to introduce the concept of a library.

IIUC the organizations that most strongly pushed for this feature are big companies with large codebases. These tend not to be the kinds of orgs that just casually pull in dependencies from PyPI on a whim; I think it more likely that the quantity of first-party code was so large that importing all of it on startup was causing problems.

What would your alternative look like?

I wouldn't be surprised if static typing had something to do with it.

I felt the opposite, because Python isn’t a great language. It won because of Google, fast prototyping, and its ML interop (e.g. pandas, numpy), but as a language it’s always been subpar.

Indentation is a horrible decision (there’s a reason no other language went this way), which led to simple concepts like blocks/lambdas having pretty wild constraints (only one line??)

Type decoration has been a welcome addition, but too slowly iterated on and the native implementations (mypy) are horribly slow at any meaningful size.

Concurrency was never good and its GIL+FFI story has boxed it into a long-term pit of sadness.

I’ve used it for years, but I’m happy to see it go. It didn’t win because it was the best language.

AI benefits from tools to verify its halucinations. That's much easier in a typed and compiled language. Then have a language that can't be monkey patched at runtime and the confidence increases even more.

If you mean "easy to get something out of it" then yeah, it's great.

Typescript wins in terms of training data IMHO, by which I mean that the training data is large enough that AI does great with TS, and the language is (IMHO) superior to Python in many ways.

I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)

a lot of the training data is either for python 2 or just generally very low quality

The tons of python code would be great training data if there was any consistency across the ecosystem. Yet every project I've touched required me to learn it's unique style. Then I'd imagine they practically poisoned half the training set because python2 is subtly different.

You can test on the device directly, without needing to recompile to try something.

Around the same time (early 90s) Java was designed with high isolation in mind but the goal and vision was very different. And Java had its own problems.

I'm saying that because at some point the security problem is gonna really hurt the python ecosystem.

Yes it strains at the big to huge project end, not recommended to take it there. Still there are better tools to help now.

> * Web sites: Typescript, or maybe Go.

lol, no. Just no. Python is far superior for website backends unless perhaps you're running one of the top 20 websites in the world.

As a now deleted comment pointed out, lazy imports had been requested forever. They were rejected forever and were accepted just when BigCorps wanted them.

Python-dev now is paid to shore up the failed Instagram stack.

both lazy imports and free threading have been proposed ages ago, they both went through several iterations before a good design was settled upon and made it into the language.

in the case of lazy imports the big corps were the ones doing the experimentation and iteration. the feature didn't make it into the language "just when big corps wanted them"; the instagram stack you allude to already had its own fork of cpython with lazy imports added years ago, and that is not the design that ended up getting adopted by upstream cpython, though some of the people working on it also collaborated on the PEP that finally did make it in.

It was accepted just as multiple large corporations with competent teams of internal tool departments ended up forking the interpreter to support lazy imports and demonstrated empirically that the idea has merit.

I too am outraged that a product would prioritize its biggest users.

Uhm what? All of those things are totally ordinary.

> All of those things are totally ordinary. reply

I would need some evidence of that.