Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions
saghm 14 minutes ago [-]
Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for years
boxed 1 hours ago [-]
Yes, 3.15+
rad120 1 hours ago [-]
Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports (1% of which are probably Shai Hulud now).
And now even type imports are apparently so slow that you have to disable them if unused during the normal untyped execution.
If Instagram or others wants a professional language, they should switch to Go or PHP instead of shoehorning strange features into a language that wasn't built for their use cases.
stingraycharles 1 hours ago [-]
> 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.
sigmoid10 1 hours ago [-]
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.
saghm 19 minutes ago [-]
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 writing is something that runs with no dependencies, but it's a pretty terrible experience as soon as you try to introduce the concept of a library.
kokada 14 minutes ago [-]
> it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones
Counter-example is Go and init() function.
stevesimmons 18 minutes ago [-]
What would your alternative look like?
novov 53 minutes ago [-]
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.
afH12 45 minutes ago [-]
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.
brookst 28 minutes ago [-]
I too am outraged that a product would prioritize its biggest users.
saghm 15 minutes ago [-]
Is the biggest user larger than the combined set of individual users who had asked for (or would benefit from) the same thing? I honestly don't know, but I don't think that things are always as simple as you're implying in a world where we have the collective action problem.
formerly_proven 47 minutes ago [-]
On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.
1 hours ago [-]
ziml77 51 minutes ago [-]
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.
JohnKemeny 1 hours ago [-]
> 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.
Yeah, but applied to counters it would be the symmetric difference between multisets, which doesn't have a natural definition. If I understood the proposal they'd be defining it as absolute value of the difference of the counts, which isn't even associative.
If they only considered parities it could be interpreted as addition in F_2, which is more natural, but I'd still agree that it's hard to see how you'd use something like this in practice.
brianwawok 2 hours ago [-]
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.
BOOSTERHIDROGEN 47 minutes ago [-]
Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?
stuaxo 1 hours ago [-]
This is straightforward in the first instance, but how do you see maintenance of those projects going forward - especially adding more complex features ?
I can see one way forward being to prototype them in python and convert.
physicsguy 1 hours ago [-]
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.
LtWorf 1 hours ago [-]
I think the purpose of go is to write CRUD. Stray from that and you're on your own.
zabzonk 37 minutes ago [-]
Three things I find unlikely about this:
- You wrote 100K lines of code (I've worked on several large C++ projects that were far smaller)
- You wrote those lines in Python (surely the whole point of Python is to write less code)
- You deleted them (never delete anything, isn't this what modern VCS is all about?)
But whatever floats your boat.
dkersten 20 minutes ago [-]
> You deleted them (never delete anything, isn't this what modern VCS is all about?)
The person said: "deleted 100k+ lines this year already moving them to faster languages"
Are you saying that when you move code to another language/rewrite in another language, you leave the original languages code in your repo?
They didn't say they deleted it from their git history. I delete code all the time (doesn't mean its "gone", just that its not in my git head).
zabzonk 3 minutes ago [-]
Well, they deleted it from somewhere. As I assumed they were using a VCS I assumed they deleted it from that. Or are they really short of disk space?
throwatdem12311 12 minutes ago [-]
100k lines is tiny what are you on about, especially in the monolithic app sass world where many Fyll stack apps that handle all business ops are probably written with Django.
Our entire business runs on 300k lines of Ruby (on Rails) and I can keep most of the business logic in my head. I would say our codebase is not exactly “tiny” and just cracking the ceiling into “smal” territory. And comparatively, people probably write even less code in equivalent rails apps to django ones. 100k lines of C++ is miniscule.
Obviously “deleting code” in this context doesn’t mean purging version control history but the current state of the codebase.
zabzonk 5 minutes ago [-]
> 100k lines is tiny
No, no, it is not, or at least not in my experience (I do not and never have done web development - medium performance C++ code - I don't see how I could write, understand and support 100K lines of code in this area).
And so, what does your Ruby code actually do?
squirrellous 18 minutes ago [-]
Uhm what? All of those things are totally ordinary.
zabzonk 11 minutes ago [-]
> All of those things are totally ordinary.
reply
I would need some evidence of that.
shankysingh 2 hours ago [-]
Thats very intersting, If I may ask was it from professional projects or personal projects?
mountainriver 2 hours ago [-]
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
prodigycorp 1 hours ago [-]
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.
tyre 55 minutes ago [-]
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.
zabzonk 27 minutes ago [-]
> there’s a reason no other language went this way)
Except of course for those that did, Haskell, Fortran for example.
groundzeros2015 39 minutes ago [-]
I’m always baffled when language complaints come down to syntax
dkersten 17 minutes ago [-]
Typescript wins in terms of training data IMHO, by which I mean that the training data is large enough that AI does great with TS, and the language is (IMHO) superior to Python in many ways.
I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)
CuriouslyC 3 minutes ago [-]
It turns out that volume of training data isn't the most important thing. Elixir beats Kotlin and C#, which beat pretty much everything else. Kotlin is probably the sweet spot for most things.
rplnt 30 minutes ago [-]
AI benefits from tools to verify its halucinations. That's much easier in a typed and compiled language. Then have a language that can't be monkey patched at runtime and the confidence increases even more.
If you mean "easy to get something out of it" then yeah, it's great.
lexicality 1 hours ago [-]
a lot of the training data is either for python 2 or just generally very low quality
prodigycorp 59 minutes ago [-]
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?
stuaxo 1 hours ago [-]
The quality issue doesn't seem unique to Python.
The versioning issue I've seen across libraries that version change in many languages.
I don't tend to hit Python 2 issues using LLMs with it, but I do hit library things (e.g. Pydantic likes to make changes between libraries - or loads of the libraries used a lot by AI companies).
lsbehe 1 hours ago [-]
The tons of python code would be great training data if there was any consistency across the ecosystem. Yet every project I've touched required me to learn it's unique style.
Then I'd imagine they practically poisoned half the training set because python2 is subtly different.
LtWorf 1 hours ago [-]
You can test on the device directly, without needing to recompile to try something.
deppep 1 hours ago [-]
i don’t really see it this way. the value of a token in Python is much higher than it is in lower-level language
1 hours ago [-]
sunshine-o 8 minutes ago [-]
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 ...
22 minutes ago [-]
Rendered at 13:29:30 GMT+0000 (Coordinated Universal Time) with Vercel.
And now even type imports are apparently so slow that you have to disable them if unused during the normal untyped execution.
If Instagram or others wants a professional language, they should switch to Go or PHP instead of shoehorning strange features into a language that wasn't built for their use cases.
Just because you don’t like a feature doesn’t mean it’s because of AI and bad code.
Counter-example is Go and init() function.
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.
Python-dev now is paid to shore up the failed Instagram stack.
Check out symmetric difference
https://en.wikipedia.org/wiki/Symmetric_difference
If they only considered parities it could be interpreted as addition in F_2, which is more natural, but I'd still agree that it's hard to see how you'd use something like this in practice.
I can see one way forward being to prototype them in python and convert.
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.
- You wrote 100K lines of code (I've worked on several large C++ projects that were far smaller)
- You wrote those lines in Python (surely the whole point of Python is to write less code)
- You deleted them (never delete anything, isn't this what modern VCS is all about?)
But whatever floats your boat.
The person said: "deleted 100k+ lines this year already moving them to faster languages"
Are you saying that when you move code to another language/rewrite in another language, you leave the original languages code in your repo?
They didn't say they deleted it from their git history. I delete code all the time (doesn't mean its "gone", just that its not in my git head).
Our entire business runs on 300k lines of Ruby (on Rails) and I can keep most of the business logic in my head. I would say our codebase is not exactly “tiny” and just cracking the ceiling into “smal” territory. And comparatively, people probably write even less code in equivalent rails apps to django ones. 100k lines of C++ is miniscule.
Obviously “deleting code” in this context doesn’t mean purging version control history but the current state of the codebase.
No, no, it is not, or at least not in my experience (I do not and never have done web development - medium performance C++ code - I don't see how I could write, understand and support 100K lines of code in this area).
And so, what does your Ruby code actually do?
I would need some evidence of that.
All of our services we were our are significantly faster and more reliable. We used Rust, it wasn’t hard to do
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.
Except of course for those that did, Haskell, Fortran for example.
I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)
If you mean "easy to get something out of it" then yeah, it's great.
The versioning issue I've seen across libraries that version change in many languages.
I don't tend to hit Python 2 issues using LLMs with it, but I do hit library things (e.g. Pydantic likes to make changes between libraries - or loads of the libraries used a lot by AI companies).
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 ...