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

211–220 of 236 posts

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

#211

Post by Hamuko »

kokada wrote: 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?

It's one of the headline features of Python 3.15 (hence why it's not in this article). It's even mentioned as the first thing on the What's New doc, so I'm definitely counting it as a "headline feature".

Personally, can't wait. It was just this week that I observed a Python process running out of memory because a module import that's not being used during the process was added to the application, and the memory usage went over a critical threshold because of that.

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

#212

Post by amelius »

mountainriver wrote: post #5
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.

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

> We used Rust

The problem with Rust is that you have to rethink your memory management architecture. I think Go is an easier choice.

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

#213

Post by amelius »

drchaim wrote: post #104

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.

Is anyone working on a more capable Python-like language which also interfaces well with Python but without the baggage?

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

#214

Post by anthk »

mountainriver wrote: post #5
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.

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

Prolog and Lisp will survive because contrary to LLM they know what reproducibility means instead of what LLM's slop around were by design they are stacking errors over time.

AI can't compete against the classical AI where both Prolog and Lisp have tons of experience on contraint logic programming and expert systems. With AI you can throw up tons of RAM and VRAM (> $12000) and yet proper designs with Prolog with outperform these by a huge gap.

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

#215

Post by pansa2 »

amelius wrote: post #213
drchaim wrote: post #104

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.

Is anyone working on a more capable Python-like language which also interfaces well with Python but without the baggage?

Mojo?

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

#216

Post by evilduck »

groundzeros2015 wrote: post #30
tyre wrote: post #24

Earlier quoted context omitted.

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

I'm baffled how you think syntax doesn't matter. Syntax affects how hard something is to understand when you read it, how hard it is to physically input, how hard it is to make mistakes, how hard it is to parse, interpret or compile.

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

#218

Post by frankwiles »

sgt wrote: post #196
sinpif wrote: post #59

Earlier quoted context omitted.

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

Or just use Django. You can later identify hot spots and bottlenecks and spin out Go services where applicable.

This is the way

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

#219

Post by meowface »

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.

IMO this is bad, but a formatter that autofixes it would be fine

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

#220

Post by 0cf8612b2e1e »

Hamuko wrote: post #211
kokada wrote: 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?

It's one of the headline features of Python 3.15 (hence why it's not in this article). It's even mentioned as the first thing on the What's New doc, so I'm definitely counting it as a "headline feature". Personally, can't wait. It was just this week that I observed a Python process running out of memory because a module import that's not being used during the process was added to the application, and the memory usage…

I am left wondering when to use it. Every import, all the time? It is an optimization that benefits some pathological scenarios, but not sure I want to introduce bikeshedding in what is/not lazy.
Post reply on HN