3.1415.. Pithon??
Python 3.14 is here. How fast is it?
251–260 of 579 posts
Re: Python 3.14 is here. How fast is it?
#252Pi-thon
Re: Python 3.14 is here. How fast is it?
#253Tangential, but I practically owe my life to this guy. He wrote the flask mega tutorial in what I followed religiously to launch my first website. Then right before launch, in the most critical part of my entire application; piping a fragged file in flask. He answered my stackoverflow question, I put his fix live, and the site went viral. Here's the link for posterity's sake https://stackoverflow.com/a/34391304/41802…
> flask Off-topic, but I absolutely loathe new Flask logo. Old one[0] has this vintage, crafty feel. And the new one[1] looks like it was made by a starving high schooler experimenting with WordArt. [0] - https://upload.wikimedia.org/wikipedia/commons/3/3c/Flask_lo... [1] - https://flask.palletsprojects.com/en/stable/_images/flask-na...
What the…? I guess I’ve been reaching for FastAPI instead of flask these days because I had no idea this happened. Didn’t all the pallets projects have the old timey logos? I wonder what happened.
Re: Python 3.14 is here. How fast is it?
#254Tangential, but I practically owe my life to this guy. He wrote the flask mega tutorial in what I followed religiously to launch my first website. Then right before launch, in the most critical part of my entire application; piping a fragged file in flask. He answered my stackoverflow question, I put his fix live, and the site went viral. Here's the link for posterity's sake https://stackoverflow.com/a/34391304/41802…
Similar story here. Pleasant to work with too.
The accessibility of this material and also the broader python ecosystem is truly incredible. After reflecting on this recently, started finding ways to give back/donate/contribute.
Re: Python 3.14 is here. How fast is it?
#255Tangential, but I practically owe my life to this guy. He wrote the flask mega tutorial in what I followed religiously to launch my first website. Then right before launch, in the most critical part of my entire application; piping a fragged file in flask. He answered my stackoverflow question, I put his fix live, and the site went viral. Here's the link for posterity's sake https://stackoverflow.com/a/34391304/41802…
> flask Off-topic, but I absolutely loathe new Flask logo. Old one[0] has this vintage, crafty feel. And the new one[1] looks like it was made by a starving high schooler experimenting with WordArt. [0] - https://upload.wikimedia.org/wikipedia/commons/3/3c/Flask_lo... [1] - https://flask.palletsprojects.com/en/stable/_images/flask-na...
The usual crap when either some "business" or some "designer" types come in
Re: Python 3.14 is here. How fast is it?
#256Earlier quoted context omitted.
I didn't know that they have the new logo before reading your comment. Been 2 years since I last searched flask but yeah the old logo was vintage and I also preferred the old logo and the new logo feels mid/sucks. The old logo is much better.
Old logo is impossible to resize and present on any assets that aren't rectangular. Flask isn't a country podunk restaurant
>Old logo is impossible to resize and present on any assets that aren't rectangular.
Who the fuck cares? That never hurt flask from becoming a well beloved widely adopted tidy framework.
And it's trivial to "resize and present" the old log on "assets that aren't rectangular"...
>Flask isn't a country podunk restaurant
Yeah, apparently by the new logo it's a generic mall fast food chain restaurant for people with zero taste
Re: Python 3.14 is here. How fast is it?
#257Earlier quoted context omitted.
This might have been your experience, but mine has been very different. In my experience a typical python workload is 50% importing python libraries, 45% slow python wrapper logic and 5% fast native code. I spend a lot of time rewriting the python logic in C++, which makes it 100x faster, so the resulting performance approaches "10% fast native logic, 90% useless python imports".
Imports being slow is annoying, but only matters to short running code.
Many simple scripts at my work that more or less just argparse and fire off an HTTP request spend half a minute importing random stuff because of false deps and uncommon codepaths. For some unit tests it's 45 seconds, substantially longer than the time taken to run the test logic.
In dev cycles most code is short-running.
Re: Python 3.14 is here. How fast is it?
#258Earlier quoted context omitted.
This is a total red herring, x86 has over 30 years of backwards compatability and the same goes for the basic peripherals. The real reason for software churn isn't hardware churn, but hardware expansion. It's well known that software expands to use all available hardware resources (or even more, according to Wirth's law).
Try running software from 1995 on a brand new system and you'll find all sorts of fun reasons why it's more complicated than that.
I don’t think I can take that claim by itself as necessarily implying the cause is hardware. Consumer OSes were on the verge of getting protected memory at that time, as an example of where things were, so if I imagine “take an old application and try to run it” then I am immediately imagining software problems, and software bit rot is a well-known thing. If the claim is “try to run Windows 95 on bare metal”, then…well actually I installed win98 on a new PC about 10 years ago and it worked. When I try to imagine hardware changes since then that a kernel would have to worry about, I’m mostly coming up with PCI Express and some brave OEMs finally removing BIOS compatibility and leaving only UEFI. I’m not counting lack of drivers for modern hardware as “hardware still changes” because that feels like a natural consequence of having multiple vendors in the market, but maybe I could be convinced that is a fundamental change in and of itself…however even then, that state of things was extremely normalized by the 2000s.
Re: Python 3.14 is here. How fast is it?
#259Earlier quoted context omitted.
> There's no reason we can't be writing code that lasts 100 years. Code is just math. In theory, yes. In practice, no, because code is not just math, it's math written in a language with an implementation designed to target specific computing hardware, and computing hardware keeps changing. You could have the complete source code of software written 70 years ago, and at best you would need to write new code to emulat…
This is a total red herring, x86 has over 30 years of backwards compatability and the same goes for the basic peripherals. The real reason for software churn isn't hardware churn, but hardware expansion. It's well known that software expands to use all available hardware resources (or even more, according to Wirth's law).
x86 doesn't have magical backwards compatibility powers.
The amazing backwards compatibility of Windows is purely due to the sheer continuous effort of Microsoft.
Re: Python 3.14 is here. How fast is it?
#260Really pleasing to see how smooth the non-GIL transition was. If you think about 2->3 python this was positively glorious.
And that it gets into spitting range of standard so fast is really promising too. That hopefully means the part not compatible with it get flushed out soon-ish