Live data from Hacker News

Python 3.15: features that didn't make the headlines

blog.changs.co.uk

21–30 of 236 posts

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

#21
post #4

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?

3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

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

#22
> 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

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

#23

Earlier quoted context omitted.

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.

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

That could be it. I still see LLMs fail a set of static typing challenges that I created a couple years ago as a benchmark. Google models still fail it. I wonder if the lack of typing in a lot of the training data makes python harder to reason about?

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

#24

Earlier quoted context omitted.

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.

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.

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

#25
post #13
post #4

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?

[flagged]

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.

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

#26
post #19
post #13

Earlier quoted context omitted.

[flagged]

[deleted]

But also great for speed. Larger libraries can take a measurable amount of time to import (even if they have no transitive dependencies). If only some of your code paths actually need the large library then it makes sense to import it lazily. Without lazy you have to do it conditionally which can lead to the imports happening in strange places rather than all being listed out at the top of the file.

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

#27

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?

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

#28
post #13
post #4

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?

[flagged]

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

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

#29
post #25
post #13

Earlier quoted context omitted.

[flagged]

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.

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.

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

#30
post #24

Earlier quoted context omitted.

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.

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, bu…

I’m always baffled when language complaints come down to syntax
Post reply on HN