Live data from Hacker News

Python 3.15's JIT is now back on track

fidget-spinner.github.io

191–200 of 330 posts

Re: Python 3.15's JIT is now back on track

#191
post #78

I always wanted this for Python but now that machines write code instead of humans I feel like languages like Python will not be needed as much anymore. They're made for humans, not machines. If a machine is going to do the dirty work I want it to produce something lean, fast, and strictly verified.

AI, write me that sqlalchemy clone in

Re: Python 3.15's JIT is now back on track

#194

Python really needs to take the Typescript approach of "all valid Python4 is valid Python3". And then add value types so we can have int64 etc. And allow object refs to be frozen after instantiation to avoid the indirection tax. Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Most things don't change, and if they do they change on startup (e…

That was how the Mojo language started. And then soon after the hype they said that being a superset of Python was no longer the goal. Probably because being a superset of Python is not a guarantee for performance either.

Re: Python 3.15's JIT is now back on track

#196
post #174

Earlier quoted context omitted.

Not what you wrote. Also CPython 3.10 is not EOL so library authors won't be using anything from 3.11 anyway.

[flagged]

You've both been here long enough to know that this kind of sniping should be avoided here.

Re: Python 3.15's JIT is now back on track

#197
post #100

Earlier quoted context omitted.

> Python essentially bet on UTF-32 (with space-saving optimisations) How so? Python3 strings are unicode and all the encoding/decoding functions default to utf-8. In practice this means all the python I write is utf-8 compatible unicode and I don't ever have to think about it.

UTF-32 allows for constant time character accesses, which means that mystr[i] isn't O(n). Most other languages can only provide constant time access for code units.

UTF-32 allows for constant time access to code points. Neither UTF-8 nor UTF-16 can do the same (there are 2 to the power of 20 valid code points, though not all are in use).

While most characters might be encodable as a single code point, Python does not normalize strings, so there is no guarantee that even relatively normal characters are actually stored as single code points.

Try this in Python:

  s = "a\u0308"
  print(s)
  print(s[0])
You will see:

  ä
  a

Re: Python 3.15's JIT is now back on track

#198

Earlier quoted context omitted.

I wasn't aware that migrating projects off Cobol has become cheap and it would only take a Claude subscription. In my experience, the problem had always been maintaining the business logic and any integrations with third-party software that also may be running legacy code-bases or have been abandoned. It can get quite complicated, from what I've seen. Now of course if you're talking about well maintained code-bases w…

IBM shares fell 13% in a single day in last month: "IBM Sinks Most Since 2000 as Anthropic Touts Cobol Tool" https://finance.yahoo.com/news/ibm-sinks-most-since-2000-210... It may not be "cheap", but possibly cheaper than IBM's consulting.

IBM share price is back to where it was pre-Anthropic press release.

Re: Python 3.15's JIT is now back on track

#199

Python really needs to take the Typescript approach of "all valid Python4 is valid Python3". And then add value types so we can have int64 etc. And allow object refs to be frozen after instantiation to avoid the indirection tax. Sensible type-annotated python code could be so much faster if it didn't have to assume everything could change at any time. Most things don't change, and if they do they change on startup (e…

> Python really needs to take the Typescript approach of "all valid Python4 is valid Python3"

It is called type hints, and is already there. TS typing doesn't bring any perf benefits over plain JS.

Re: Python 3.15's JIT is now back on track

#200

Earlier quoted context omitted.

Let's not get started on the cached shared object refs for small integers....

What realistic use case do you have for caring about whether two integers of the same value are distinct objects? Modern versions of Python warn about doing unpredicatble things with `is` exactly because you are not supposed to do those things. Valid use cases for `is` at all are rare.

> Valid use cases for `is` at all are rare.

There might not be that many of them, depending on how you count, but they're not rare in the slightest. For example, you have to use `is` in the common case where you want the default value of a function argument to be an empty list.

Post reply on HN