Live data from Hacker News

Python 3.15: features that didn't make the headlines

blog.changs.co.uk

101–110 of 236 posts

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

#101

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

[deleted]

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

#102

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

[deleted]

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

#103

Earlier quoted context omitted.

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

Now I'm wishing for a single cross-language library, that I can somehow inject into every compiler/runtime/checker to get this, but with a single source of truth and across a wide range of languages. I hit this damn issue all the time, writing code in one language for another, would truly be a bliss to have that problem solved once and for all.

If you had a "canonical datastructure database", you could have very short annotations on every standard library for any language that indexes a function to their canonical name. After that you only need to update the database.

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

#105

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

There is no security barrier at all in UNIX(-like) Os's between a caller/callee, this is not thing that python can just fix.

There are ways to harden and/or reduce privileges, but shells/scripting languages will always have this issue on any modern OS.

The UNIX way to help prevent that is really to run processes as another user, but people seem to refuse to do so. You should always expect any process running as your UID to be able to access any data owned or visible to your UID.

While it is possible to reduce the risk of disclosure, they are all wack-a-mole preventions protecting the low hanging fruit, not absolute guarantees.

That is purely due to how UNIX works [0]

[0] https://man7.org/linux/man-pages/man7/credentials.7.html

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

#106
post #60

funny how we may have to wait even longer for llms to pick up this update in their pre-training

Is there seriously no solution to this? Perhaps something we fan do post training? For example add the new features to SKILLS.md? But the trade-off here is of course tokens.

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

#107

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?

Programs have to run in a lot of different contexts, not just as servers, and for some of those contexts (especially say glueing together other programs), an interpreted language is more convenient and easier to work with. In fact, unless I care about performance, I'm going to use an interpreted language because having the source close at hand when something breaks just turns out to be super useful.

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

#108
post #29
post #25

Earlier quoted context omitted.

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.

both lazy imports and free threading have been proposed ages ago, they both went through several iterations before a good design was settled upon and made it into the language.

in the case of lazy imports the big corps were the ones doing the experimentation and iteration. the feature didn't make it into the language "just when big corps wanted them"; the instagram stack you allude to already had its own fork of cpython with lazy imports added years ago, and that is not the design that ended up getting adopted by upstream cpython, though some of the people working on it also collaborated on the PEP that finally did make it in.

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

#109
post #93

Earlier quoted context omitted.

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

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.

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

#110
post #11

Earlier quoted context omitted.

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.

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.
Post reply on HN