Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.14 is here. How fast is it?

blog.miguelgrinberg.com

Post reply on HN
Print view View original

271–280 of 579 posts

Re: Python 3.14 is here. How fast is it?

#271

Post by thaumasiotes »

wiseowise wrote: post #134
nadermx wrote: post #10

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

Huh. What most stands out to me about the logo, old and new, is that it clearly depicts a drinking horn instead of a flask.

Re: Python 3.14 is here. How fast is it?

#272

Post by rowanG077 »

ncruces wrote: post #212
kstrauser wrote: post #8

Earlier 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…

> 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 back out for 3 seconds. > You could rewrite that in Rust and it wouldn't be any faster. I was asked to rewrite some NumPy image processing in C++, because NumPy worked fine for 1024px test images but balked when given 40 Mpx photos. I cut the runtime by an order of magnitude for…

Same with opencv and even sometimes optimized matrix libraries in pure C++. These are all highly optimized. But often when you want to achieve something you have to chain stuff which quickly eats up a lot of cycles, just by copying stuff around and having multiple passes that the compiler is unable to fuse. You can often pretty easily beat that even if you are not an optimization god by manual loop fusion.

Re: Python 3.14 is here. How fast is it?

#273

Post by 8organicbits »

didip wrote: post #21

Every time I hear news about Python language itself, it sadden me that, in 2025, PyPy is still a separate distinct track from mainline Python. That said, I wonder if GIL-less Python will one day enable GIL-less C FFI? That would be a big win that Python needs.

Can you clarify the concern? Starting from C I've come to expect many dialects across many compiler implementations. It seems healthy and encourages experimentation. Is it not a sign of a health language ecosystem?

Pypy compatibility with cpython seems very minor in comparison https://pypy.org/compat.html

Re: Python 3.14 is here. How fast is it?

#274

Post by Iuz »

Is fold comment a option based on karma or something? I loved the most voted post here on how Miguel helped the guy but, it is unrelated and for the first time I guess I realized there is no fold so I can go to people actually talking about the article...

Re: Python 3.14 is here. How fast is it?

#275

Post by jcranmer »

KK7NIL wrote: post #242
kibwen wrote: post #185

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

30 years ago, right before Windows 95 came out, Windows was a 16-bit OS and the modern versions of Windows no longer support 16-bit programs. PCIe came out only in 2003, and I don't know that PCIe slots can support PCI. SATA is also from 2003. Even USB originally came out in 1996, and the only pre-USB connector slot I have on my computer is a PS/2 port (which honestly surprises me). For monitor connections, VGA and DVI (1999!) have died off, and their successors (HDMI, DisplayPort) are only in the 2000's.

So pretty much none of the peripherals--including things like system memory and disk drives, do note--from a computer in 1995 can talk using any of the protocols a modern computer supports (save maybe a mouse and keyboard) and require compatibility adapters to connect, while also pretty much none of the software works without going through custom compatibility layers. And based on my experience trying to get a 31-year old Win16 application running on a modern computer, those compatibility layers have some issues.

Re: Python 3.14 is here. How fast is it?

#276

Post by lmm »

KK7NIL wrote: post #265
Night_Thastus wrote: post #249

Earlier quoted context omitted.

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.

Do you have any examples that aren't because of the OS (as in, not trying to run a 90's game on Windows 11) or specialized hardware (like an old Voodoo GPU or something)?

If you restrict yourself to programs that don't need an OS or hardware, you're going to be looking at a pretty small set of programs.

Re: Python 3.14 is here. How fast is it?

#277

Post by api »

kibwen wrote: post #185
feoren wrote: post #82

Earlier 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…

> 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 correct when it comes to bare metal execution.

You can always run code from any time with emulation, which gives the “math” the inputs it was made to handle.

Here’s a site with a ton of emulators that run in browser. You can accurately emulate some truly ancient stuff.

https://www.pcjs.org/

Re: Python 3.14 is here. How fast is it?

#278

Post by famouswaffles »

KK7NIL wrote: post #264
famouswaffles wrote: post #259

Earlier quoted context omitted.

x86 doesn't have magical backwards compatibility powers. The amazing backwards compatibility of Windows is purely due to the sheer continuous effort of Microsoft.

> x86 doesn't have magical backwards compatibility powers. I never said it did; other ISAs have similar if not longer periods of backwards compatability (IBM's Z systems architecture is backwards compatible with the System/360 released in 1964). > The amazing backwards compatibility of Windows is purely due to the sheer continuous effort of Microsoft. I never mentioned Windows but it's ridiculous to imply its backwar…

>I never mentioned Windows but it's ridiculous to imply its backwards compatability is all on Microsoft.

I never said that. Windows was just an easy example.

>Show me a single example of a backwards breaking change in x86 that Windows has to compensate for to maintain backwards compatability.

- The shift from 16-bit to 32-bit protected mode with the Intel 80386 processor that fundamentally altered how the processor managed memory.

- Intel 80286 introduced a 24-bit address bus to support more memory, but this broke the address wraparound behavior of the 8086.

- The shift to x86-64 that Microsoft had to compensate with emulation and WOW64

Any many more. That you think otherwise just shows all the effort that has been done.

Re: Python 3.14 is here. How fast is it?

#279

Post by hn_acc1 »

Night_Thastus wrote: post #249
KK7NIL wrote: post #242

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

Pretty sure if I downloaded and compiled Tcl/Tk 7.6.x source code on a modern Linux box, it would run my Tcl/Tk 7.6.x "system monitor" code from 1995 or 1996 just fine.

Re: Python 3.14 is here. How fast is it?

#280

Post by psychoslave »

zenmac wrote: post #269
psychoslave wrote: post #136

Earlier quoted context omitted.

Stability is for sure a very seducing trait. Also I can totally understand the fatigue of the chase for the next almost already obsolete new stuff. >There's no reason we can't be writing code that lasts 100 years. There are many reason this is most likely not going to happen. Code despite best effort to achieve separation of concern (in the best case) is a highly contextual piece of work. Even with a simple program w…

Don't know about 100 years, but old static web page from lat 90's with js on wayback machine still works. There might be something to this static html css to archive content maybe even little programs.

Yes, and we only need a browser to achieve that, the kind of piece of software well known to be small, light and having only sporadic changes introduced into them. :D

That's actually a good moment to wander about what an amazing they are, really.

Post reply on HN