It's slow.
Get back to work.
Python 3.14 is here. How fast is it?
121–130 of 579 posts
Re: Python 3.14 is here. How fast is it?
#122Tangential, 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…
You have made my day, sir. :)
Absolutely love seeing like a dozen people piling on Mr Grinberg to show gratitude for his work, and indeed the even little things he does to help uplift others in the field. It’s a good reminder that a small helpful contribution, or bit of teaching given at the right time, can be so valuable!
Re: Python 3.14 is here. How fast is it?
#123I'm thankful they included a compiled language for comparison, because most of the time when I see Python benchmarks, they measure against other versions of Python. But "fast python" is an oxymoron and 3.14 doesn't seem to really change that, which I feel most people expected given the language hasn't fundamentally changed. This isn't a bad thing; I don't think Python has to be or should be the fastest language in th…
I've been writing Python professionally for a couple of decades, and there've only been 2-3 times where its performance actually mattered. When writing a Flask API, the timing usually looks like: process the request for .1ms, make a DB call for 300ms, generate a response for .1ms. Or writing some data science stuff, it might be like: load data from disk or network for 6 seconds, run Numpy on it for 3 hours, write it…
Sure then you get a developer who decides to go with Flask for an embedded product and it's an eye watering slog.
Re: Python 3.14 is here. How fast is it?
#124What are the reasons why nobody uses pypy?
Because in the real world, for code where performance is needed, you run the profiler and either find that the time is spent on I/O, or that the time is spent inside native code.
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".
Re: Python 3.14 is here. How fast is it?
#125Earlier quoted context omitted.
Did you throw any money his way?
Didn't know he had a patreon, just set it up so the first 100 people, since that's the max it allowed, can get a 1 year access to his discord https://www.patreon.com/miguelgrinberg/redeem/f/C28EB241BB
Didn’t even know you could do this, but what a cool way to do that — helping others learn from him while also materially supporting him.
Re: Python 3.14 is here. How fast is it?
#126Earlier quoted context omitted.
I've been writing Python professionally for a couple of decades, and there've only been 2-3 times where its performance actually mattered. When writing a Flask API, the timing usually looks like: process the request for .1ms, make a DB call for 300ms, generate a response for .1ms. Or writing some data science stuff, it might be like: load data from disk or network for 6 seconds, run Numpy on it for 3 hours, write it…
That's because you're doing web stuff. (I/O limited). So much of our computing experience has been degraded due to this mindset applied more broadly. Despite a steady improvement in hardware, my computing experiences have been stagnating and degraded in terms of latency, responsiveness etc. I'm not going to even go into the comp chem simulations I've been running, or that about 1/3 the stuff I do is embedded. I do st…
> That's because you're doing web stuff.
I guess you didn't notice where he talked about running numpy?
Re: Python 3.14 is here. How fast is it?
#127Earlier quoted context omitted.
Because in the real world, for code where performance is needed, you run the profiler and either find that the time is spent on I/O, or that the time is spent inside native code.
Also, that engineer time you would spend optimizing for performance costs more than just throwing more hardware at it.
For cloud jobs that can be true, but for single threaded dev-in-the-loop work you can't just buy a 100x faster processor than the one on their dev machine, and the latency is expensive workflow friction.
Re: Python 3.14 is here. How fast is it?
#128Earlier quoted context omitted.
> Why not use a faster language in the first place? Well for the obvious reason that there isn't really anything like a Jupyter notebook for C. I can interactively manipulate and display huge datasets in Python, and without having to buy a Matlab license. That's why Python took off in this area, really
I agree - Jupyter notebook is really the key feature Python has that makes it attractive for research/scientific computing. I would say the REPL too but until very recently it was extremely shoddy so I doubt many people did any serious work in it.
> I would say the REPL too but until very recently it was extremely shoddy
Can you elaborate? I've been using the Python REPL for more than two decades now, and I've never found it to be "shoddy". Indeed, in pretty much every Python project I work on, one of the first features I add for development is a standard way to load a REPL with all of the objects that the code works with set up properly, so I can inspect them.
Re: Python 3.14 is here. How fast is it?
#129Earlier quoted context omitted.
You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…
Except uh, nobody uses infinitesimals for derivatives anymore, they all use limits now. There's still some cruft left over from the infinitesimal era, like this dx and dy business, but that's just a backwards compatibility layer. Anyhoo, remarks like this are why the real ones use Typst now. TeX and family are stagnant, difficult to use, difficult to integrate into modern workflows, and not written in Rust.
> nobody uses infinitesimals for derivatives anymore
All auto-differentiation libraries today are built off of infinitesimals via Dual numbers. Literally state of the art.
Re: Python 3.14 is here. How fast is it?
#130What are the reasons why nobody uses pypy?
I use it where I can, unfortunately those places are usually scripts that don’t benefit from the compiler.
The project is moving into maintenance mode, if some folks want to get python-famous, go support pypy.