Python 3.15: features that didn't make the headlines • Hacker News Board

Re: Python 3.15: features that didn't make the headlines

#111

Post by MarkusQ » Thu, May 21, 2026, 5:18 PM UTC

tuveson wrote: post #109

fulafel wrote: post #93

Earlier quoted context omitted.

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'?

I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.

I hope you mean "funny" in the "hilarity ensues" sense.

Because the alternative is a rather sociopathic level of schadenfreude.

Re: Python 3.15: features that didn't make the headlines

#112

Post by jwineinger » Thu, May 21, 2026, 5:23 PM UTC

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})

Re: Python 3.15: features that didn't make the headlines

#113

Post by estebank » Thu, May 21, 2026, 5:23 PM UTC

tuveson wrote: post #109

fulafel wrote: post #93

Earlier quoted context omitted.

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'?

I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.

VisualBasic did that. I think it is a mistake. But that doesn't mean that the compiler can't detect that and tell you how to fix it instead.

Re: Python 3.15: features that didn't make the headlines

#114

Post by luckydata » Thu, May 21, 2026, 5:30 PM UTC

zem wrote: post #110

LtWorf wrote: post #11

Earlier quoted context omitted.

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

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.

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

Re: Python 3.15: features that didn't make the headlines

#115

Post by WorldMaker » Thu, May 21, 2026, 5:33 PM UTC

saghm wrote: post #94

WorldMaker wrote: post #88

Earlier quoted context omitted.

Not to mention when the single, tangible, vocal stakeholder can also be asked to be responsible for documentation (PEPs, etc) and PRs. Especially in open source there is a huge difference between "a lot of people asked about this" and "one person asked about this, but was passionate enough about it and open enough to following the process and the feedback loops to champion it all the way across the finish line".

I don't have any issue with what you're saying if that's what happened. There's quite a gap between that sort of reasoned explanation and treating concerns about large stakeholders versus large numbers of small one with derision.

For what it is worth, I was trying not to make a value judgment on it, especially not with relation to this specific instance, I was hopefully just recognizing it as a motivating factor in general open source politics. Sometimes that is quite regretful because it is anti-democratic and does look like favoritism or worse cronyism when it plays out in that way of "we listened to the person/company that built and tested a prototype and did all the work to standardize and then PR it over the many developers that wanted an idea but didn't have the time/money/bandwidth to implement it themselves".

Re: Python 3.15: features that didn't make the headlines

#116

Post by rirze » Thu, May 21, 2026, 5:34 PM UTC

1_08iu wrote: post #82

IshKebab wrote: post #56

Earlier quoted context omitted.

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 tryi…

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? M…

I agree with you; I've developed in Python for most of my career and a lot of Python criticism is malformed.

That being said, I'm starting all new large development work in Rust. Python is hard to reason about due to its dynamic nature in large codebases. And if I'm enabling strict typing everywhere, I might as well use a typed language and get a performance boost. Obviously, this is only because I'm the sole developer and using AI to improve productivity.

Work settings are completely different and one has to be a team player to find the language that works for everyone.

Re: Python 3.15: features that didn't make the headlines

#117

Post by t43562 » Thu, May 21, 2026, 5:36 PM UTC

BOOSTERHIDROGEN wrote: post #27

brianwawok wrote: post #2

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.

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

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."

Re: Python 3.15: features that didn't make the headlines

#118

Post by tuveson » Thu, May 21, 2026, 5:55 PM UTC

MarkusQ wrote: post #111

tuveson wrote: post #109

Earlier quoted context omitted.

I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.

I hope you mean "funny" in the "hilarity ensues" sense. Because the alternative is a rather sociopathic level of schadenfreude.

Yes, I say “funny” because it would be impractical and weird, definitely not a good idea. It’s already a bad enough that so many popular languages don’t (and can’t) check if a field or method is misspelled at compile time…

Re: Python 3.15: features that didn't make the headlines

#119

Post by xg15 » Thu, May 21, 2026, 5:55 PM UTC

> 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.

Re: Python 3.15: features that didn't make the headlines

#120

Post by QuesnayJr » Thu, May 21, 2026, 5:58 PM UTC

tuveson wrote: post #109

fulafel wrote: post #93

Earlier quoted context omitted.

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'?

I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.

Lisp had a package for that, DWIM, in the late 60s: https://en.wikipedia.org/wiki/DWIM.