Python 3.15: features that didn't make the headlines (blog.changs.co.uk)
173 points by rbanffy 5 hours ago
veqq 5 minutes ago
There's a good interview about Python internals and management, particularly in relation to free-threading: https://alexalejandre.com/programming/interview-with-ngoldba...
kokada 4 hours ago
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)
llimllib 3 hours ago
javcasas 2 hours ago
> 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.
kzrdude an hour ago
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?
js2 44 minutes ago
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.
kzrdude 29 minutes ago
karpetrosyan 3 hours ago
Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions
saghm 2 hours ago
Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for years
boxed 4 hours ago
Yes, 3.15+
rad120 3 hours ago
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.
stingraycharles 3 hours ago
> 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.
xtajv an hour ago
sigmoid10 3 hours ago
tremon an hour ago
novov 3 hours ago
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.
afH12 3 hours ago
formerly_proven 3 hours ago
On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.
undefined 3 hours ago
ziml77 3 hours ago
JohnKemeny 3 hours ago
> 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
qsort 2 hours ago
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.
kwon-young an hour ago
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/
brianwawok 4 hours ago
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.
stuaxo 3 hours ago
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.
BOOSTERHIDROGEN 3 hours ago
Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?
IshKebab 2 hours ago
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.
1_08iu 10 minutes ago
mixmastamyk 17 minutes ago
sinpif 2 hours ago
I'm still on the lookout for a comprehensive Django-like web framework for go. That would be an instant hit for me.
pennomi an hour ago
Same here. Django is my last holdout for Python. Everything new is go.
physicsguy 4 hours ago
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.
LtWorf 4 hours ago
I think the purpose of go is to write CRUD. Stray from that and you're on your own.
deppep 3 hours ago
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
shankysingh 4 hours ago
Thats very intersting, If I may ask was it from professional projects or personal projects?
mountainriver 4 hours ago
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
prodigycorp 4 hours ago
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.
tyre 3 hours ago
rplnt 3 hours ago
dkersten 3 hours ago
lexicality 3 hours ago
lsbehe 3 hours ago
LtWorf 4 hours ago
You can test on the device directly, without needing to recompile to try something.
zabzonk 3 hours ago
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.
dkersten 3 hours ago
> 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).
zabzonk 2 hours ago
throwatdem12311 2 hours ago
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.
zabzonk 2 hours ago
squirrellous 3 hours ago
Uhm what? All of those things are totally ordinary.
zabzonk 2 hours ago
armanj 2 hours ago
funny how we may have to wait even longer for llms to pick up this update in their pre-training
sunshine-o 2 hours ago
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 ...
surajrmal an hour ago
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.
sunshine-o 17 minutes ago
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.