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
Python 3.15: features that didn't make the headlines
101–110 of 236 posts
Re: Python 3.15: features that didn't make the headlines
#102I 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
Re: Python 3.15: features that didn't make the headlines
#103Earlier 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.
Re: Python 3.15: features that didn't make the headlines
#104Re: Python 3.15: features that didn't make the headlines
#105I 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 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
#106funny how we may have to wait even longer for llms to pick up this update in their pre-training
Re: Python 3.15: features that didn't make the headlines
#107I 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
#108Earlier 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.
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
#109Earlier 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'?
Re: Python 3.15: features that didn't make the headlines
#110Earlier 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.