Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.15: features that didn't make the headlines

blog.changs.co.uk

Post reply on HN
Print view View original

121–130 of 236 posts

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

#121

Post by tuveson »

estebank wrote: post #113
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.

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.

Sure VB ignores case, but what I want is for it to compare each method against a dictionary of similar terms. And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one. You could also assume that full-width characters or similar-looking glyphs are equivalent (BASIC was pre-Unicode, so I can forgive them for not including that).

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

#122

Post by ameliaquining »

xg15 wrote: post #119

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

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

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

#123

Post by Drakim »

xg15 wrote: post #119

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

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.

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

#124

Post by [deleted] »

Drakim wrote: post #123
xg15 wrote: post #119

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

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.

[deleted]

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

#125

Post by xg15 »

ameliaquining wrote: post #122
xg15 wrote: post #119

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

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

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.

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

#126

Post by ameliaquining »

sigmoid10 wrote: post #20
stingraycharles wrote: post #17

Earlier quoted context omitted.

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

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.

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

#127

Post by ameliaquining »

assbuttbuttass wrote: post #84
kokada wrote: post #43

Earlier quoted context omitted.

> it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones Counter-example is Go and init() function.

Also C++/Java static initialization, C# static constructors, or Rust global variable initialization, ... Most languages have this feature Afaik

Rust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.

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

#128

Post by aniou »

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.

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

#129

Post by markdown »

IshKebab wrote: post #56
BOOSTERHIDROGEN wrote: post #27

Earlier quoted context omitted.

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

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…

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

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

#130

Post by lanstin »

kokada wrote: post #43
saghm wrote: post #38

Earlier quoted context omitted.

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…

> it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones Counter-example is Go and init() function.

Static initializers in C++ - sometime ago I saw savings of some 400 ms (?) startup cost of initializing static strings from constants by moving it to some compile time thing.
Post reply on HN