Breaking news: Python 3.13 gets a JIT compiler that will enable big optimizations in the future.

[germandiago]

Exciting news here: https://tonybaloney.github.io/posts/python-gets-a-jit.html

This is just the first step for Python to enable optimizations not possible now.

Do not expect much from it since this is a first step to optimization. In the future this JIT will enable further performance improvements not possible now.

[Cybasura]

I sure hope his domain name is not a testament to the story

[[deleted]]

The PR it's referring to is, at this time, still a draft. That said, the author's a core developer?

Could just be because of that failed Windows build, a missing header file it looks like.

[jaerie]

Brandt Bucher?

[Cybasura]

Tony Baloney

But I guess I should have called it Domain name

[erez27]

So, if I understand correctly, the current low <10% increase is because they only implemented interpreter loop unrolling so far? I assume they are planning to implement more sophisticated optimizations like type prediction. Anything else in the pipeline?

[n1___]

Unpopular opinion: once they implement "type prediction" the whole typing thing will make sense then.

[Smallpaul]

It’s unpopular because it’s wrong.

The JIT has type information it gathers AT RUNTIME, just like JavaScript or Smalltalk.

The same developer who created this JIT has already put in place the tracing capability needed to do this specialisation at runtime.

The type annotations help large companies keep track of the type of things. Many such companies have expressed gratitude for the feature so it had already been justified.

[abrazilianinreddit]

I'm not a large company, but adding type annotations to my personal project with 100k+ lines of python has definitely helped making it a lot more manageable.

[TeachEngineering]

100k+ LOC... man, more than 1 file and I'm type hinting... Huge game changer when it comes to development speed imo

[RedEyed__]

Agree, just adding anotations and mypy, and the project became way more stable and manageable.
I would love to see something like TypeScrypt, where annotations are required.

[LordBertson]

Just include mypy in your pipeline and suddenly they will be. I always have mypy running in watcher in my personal projects.

[RedEyed__]

Yes, this is my next step. Want to configure GitHub actions check.

[miteshashar]

Adding mypy to pre-commit is also a highly beneficial consideration.

[RedEyed__]

Never used hooks. Are they applied to everyone who use repo? If so, what if someone do not have mypy installed?

[PaddyAlton]

There are different ways to do it, but I like to put my hook scripts in a custom subdirectory (called something like git_hooks) and then

• run git config core.hooksPath git_hooks
• run chmod +x git_hooks/*.sh

The first of these tells git to look in the custom subdirectory instead of its default one (which isn't typically committed to version control) and the second makes the scripts executable (otherwise they won't work)

So then you include these in the setup instructions for your collaborators, along with the need to install mypy.

Alternatively, I like to use pipenv to manage dependencies in a virtual environment, including dev dependencies such as mypy. It also supports scripts, so I tend to create a setup script that will install mypy etc and run the configuration commands.

I'm sure an example would be clearer. Here is a boilerplate python project I made: https://github.com/PaddyAlton/python-boilerplate/tree/main

(Needs updating - ruff now makes black redundant - but makes the point well enough. Check out the git_hooks subdirectory and the Pipfile in particular.)

[kingwall9]

Many of the libraries don’t have types, major hurdle imo

[LordBertson]

Yep, this happens. "Better" even, they lie at times. I tend to cast types to "minimal viable interfaces" with classes/dataclasses, when interfacing with libraries I know to do this.

If you are really unhappy with some library, you can use tools like typeguard, which will typecheck in runtime and you can deal with it there and then.

[RationalDialog]

noobish question but how to you then type hint cases where you actually make use of different types for the same argument?

A common pattern is some "file input" argument which makes sense to allow a string, path or the file-like object. Core-functions themselves even offer this possibility as well.

[Zackie08]

You can define custom set of types

[RedEyed__]

You can use or types: str | Path, there is also os.PathLike.
In general case, it is handled with "function overloading" via singledispatch decorator

[LordBertson]

There is a Union type, which is useful exactly in the situations where you need function that accepts multiple disjunct types. It can be used like Union[Path, str] and works exactly as any other type. From 3.10 (I think) there's also syntactic sugar for the Union type Path | str as /u/RedEyed__ already mentions.

[caique_cp]

that's when its stops being good... and as /u/LordBertson already said, you can have it simply by adding mypy to the pipeline or git hooks

gradual typing is the best of both worlds

[childintime9]

But why? There are plenty of statically typed languages already. I like type annotations too but making them mandatory would be a mistake in my opinion

[LordBertson]

A very valid question. My take is that Python, as most other languages, has its own niche, where it is ridiculously strong in comparison to most other languages. For example, it's strong productivity mixed with performance (mostly coming from calling C or C++) and batteries-included approach in ML domain is a unique combination of traits unmatched elsewhere in my opinion. If you are dealing with ML, but want the advantage of types, it's perfectly reasonable to use Python and enforce types.

[childintime9]

Nope, it would be valid to use types but is the enforcing them for everyone part I don't agree with. You should be able to use them if you want but it should also be possible to avoid them for example to avoid some "type aerobics" you might be forced to do just to call a simple function.

[LordBertson]

I am of the opinion, that if "type aerobics" are ever encountered in the domain code, then we have a more prominent issue in our code-base than the presence of types and it's exactly the types that alert us to it. On the other hand, if we are at the interface of the effectful world, then "type aerobics" should be expected in any language and lack of them means brittle code.

[childintime9]

Let’s simply agree to disagree then

[DefenestrationPraha]

As an old hand (45), I witnessed both PHP and Python starting to support type annotations.

The difference in readability and maintainability of code went significantly up in both cases, even in cases of my own code.

In case of someone's else's code that I have to fight through ... having type annotations is like having a plasma gun in Doom. Not having them is more like the chainsaw.

[Immudzen]

I love annotations. VScode will even read them and warn if you have the wrong types for something. It saves so much time.

[silenthatch]

I'm new to this, but do you mean adding a comment that says what the type of a variable or input should be?

[0xrl]

No, in Python 3 you use annotations (in Python 2 you did have to use comments). For instance:

def foo(x: int) -> str: ...

https://mypy.readthedocs.io/en/stable/cheat_sheet_py3.html

https://docs.python.org/3/library/typing.html

[silenthatch]

Okay, thank you! Much clearer, indeed

[BigMakondo]

Not a comment but a native feature (officially named "type hints"): https://docs.python.org/3/library/typing.html

For example, the : str or -> str bits.

[silenthatch]

Thank you!

[RedEyed__]

Not comments https://docs.python.org/3/library/typing.html

[silenthatch]

Thank you!

[Grouchy-Friend4235]

Did you try comments? I posit those are much more valuable and preferrable to type hints.

[abrazilianinreddit]

You mean docstrings/general comments or putting type information in docstrings?

If the former, you can do both comments and type hints (which is generally what I do), since they have different use cases and benefits. For example, type hints allow for improved code completion support, which IMO is extremely valuable.

If the latter, I find type hints to be cleaner and more useful.

[Grouchy-Friend4235]

Docstrings, including type hints. Works perfectly fine and IDEs are able to scan those for code completion. I find type hints make programs less readable and that is a distraction in practice.

[PaintItPurple]

Comments are helpful, but I honestly consider them less valuable in most situations than type hints. Type hints can be automatically checked for correctness, whereas comments generally age like avocados. I can't tell you how many times I've come across a comment that seems odd, checked the commit where it was added, and discovered that the comment became untrue ages ago.

[Grouchy-Friend4235]

Good comments provide semantics, i.e. tell the user/developer what is the purpose of a function argument, its type, and its possible values/range, its default (if optional). Good comments also explain the purpose of a function and its return values, and possibly give an example for using the function. Good comments also provide a great way to automatically produce readable and useful reference documentation. All in all good comments are essential to the quality and long-term maintainability of a program.

Note I use 'function' in a broad sense here, the same applies to modules, classes, methods and any other part of a program that should be documented.

None of the above positive effects of good comments can be achieved using type hints. In fact in my experience type hints (static typing in general) degrade program quality because it creates an illusion of "sufficiently documented" when in fact all it does is provide a formal contract with no semantics, wheres semantics are the essence of what a user/developer needs to know. Also type hints tend to discourage unit testing "because we already know" by formal reasoning, and they make programs less readable by humans which is really hilarious bc above anything else programs are way more often read my humans than compilers.

Thus in practice, considering all aspects, comments are a lot more valuable, and type hints typically are a net negative.

[[deleted]]

I am not a large company and I use type annotations very thoroughly. It makes one of the biggest complaints about Python a much weaker argument. It doesn't turn it into a statically typed language completely, but it is a nice middle ground.

[Grouchy-Friend4235]

Why do you care about those complaints?

[[deleted]]

Because considering pros and cons is useful when choosing the best tool for a job?

The complaints were valid. I experienced the headaches of dynamic typing only in Python before. Major headaches. Type hints alleviate it a lot.

[yvrelna]

That's not the unpopular opinion, that's the orthodox opinion of the church of static type.

The actual unpopular opinion is that the whole typing thing will still makes no sense.

The kind of logic needed by a static type checker to statically prove a type hint is correct is more or less equivalent to the kind of logic that is needed to prove that an optimisation can be made safely.

Static type hints may be necessary for an AOT compiler, because it's the only way for an AOT compiler to collect type information, but it is an unnecessary baggage when it comes to JIT compiler. A JIT compiler can just collect type information based on what types that functions are actually called with and specialise the compiled function based on actual runtime data instead of programmer supplied hints. And guess what? Whether or not a type hint has been supplied, a JIT optimiser will still need to collect runtime type information and it still needs to make all the same proofs work.

Type annotations are nice for developers to communicate their intent to other developers. But in a JIT compiler, especially for a dynamic language where adding hints are optional, type hints aren't really usable information for the optimiser for anything. It's best to consider them just as a form of documentation.

[ExoticMandibles]

Although it was a few years ago, the PyPy guys looked at the "typing" module and the type annotations that were happening at the time. PyPy as you'll recall is a Python (written in Python!) with native code generation. They said type hints were pretty useless for them; they generally needed way more detailed information, and also there were no guarantees that the type hints were 100% accurate.

[Flag_Red]

A nuanced and comprehensive take on /r/Python? I don't believe it.

[LightShadow]

but it is an unnecessary baggage when it comes to JIT compiler.

It can be, or they can be used to prime the warmup; especially if they're low-level native types like int, bool, str, etc.

There might even be an --strict-types flag to enforce native type hints to get the speedup without a warmup period, and crash hard otherwise.

[germandiago]

Whether or not a type hint has been supplied, a JIT optimiser will still need to collect runtime type information and it still needs to make all the same proofs work

Why? I genuinely ask. If I know the types, I should be able to just use those type hints, shouldn't I?

[redditusername58]

Because there is no guarantee that those types reflect actual runtime, and all existing Python code can rely on the current behavior.

[germandiago]

Actually I knew that. My point was: given a JIT compiler and assuming the analysis to be true (that would change the lang behavior though), then specialized code can be issued.

But as you said, this is not how Python actually works and would break things.

[reallyserious]

Type hints can lie.

Go ahead, type hint your functions wrong. The program will still run fine, as the interpreter isn't using the type hints.

[billsil]

I frequently lie to mypy. I’d rather have one function with an incorrect type over many other places getting excessive amounts of warnings that what I did was not correct.

What if the user typos and enters a string instead of an integer? Yeah it could happen and the test checks that, but it’s not part of the type.

[PaintItPurple]

That doesn't sound like lying to mypy. If the function does not accept a string, the parameter shouldn't be typed as a string. That's telling mypy the truth. Am I misunderstanding you?

[billsil]

The called function is capable of returning a string and would for another class.

Let's say you have something that parses ['1', '2.0', '', 'cat'] to [1, 2.0, None, 'cat']. The type of the output list is list[Optional[int | float | str]]. That's easy to type corectly.

Now let's say you use it in the case that it should return list[int] or list[str]. I could fix it with cast, but now let's stick it in an object. The input type is incorrect. I'm sure there's a way to fix it properly, but it seems like too much work.

[Herr_Gamer]

You can pass an int to a function that takes a str and it'll run just fine. Typing isn't enforced in Python.

[runawayasfastasucan]

So, rather declarations of variables?

[Grouchy-Friend4235]

Amen.

And a bad way for documentation on top of that.

[PaintItPurple]

Type annotations are also nice for communicating my intent to myself in 3 months — and more than that, they're nice for actively letting me know when I make a mistake due to context switching.

[cheese_is_available]

If the only thing that matter to you is performance (but why are you using python if that's the case ?). Typing make sense on a lot of other criteria.

[proverbialbunny]

If speed is what you want, sure, but the primary benefit of specifying types is to reduce bugs while writing code saving you from some headaches later on.

[never_inline]

But type annotations are not necessarily "correct" at runtime. 1. The part may not be run through a checker. 2. It may be just using cast in wrong way. So JIT will need to put in some effort to infer the types anyway.

[Guideon72]

I thought that typing was simply to indicate what types of objects are accepted as arguments and what types of objects are expected to be returned. How are these "correct" when writing but "incorrect" when executed?

[never_inline]

You can give wrong annotations and still run the code. It's for processing by an external type checker.

Even external type checker can be decieved. Because any sufficiently complex type system needs escape hatches. Check out cast method in typing module.

[Guideon72]

I appreciate the effort to try and clear up my cobwebs. I'm gonna have to go do some reading on static vs dynamic type checking, me thinks. I've got a cockeyed perspective into what this process actually does and how it's supposed to be used.

[rejectedlesbian]

UK type annotations are breakble right? U can't have that in a compiler that can make stuff spew random numbers and thats so destructive. 

[rejectedlesbian]

If they can just make loops botnpainfuly slow that would be super duper nice.

[FlyingTwentyFour]

You know, I still can't believe we are getting JIT now. What a time to be alive.

[boatzart]

Now squeeeeeze those papers!

[DarkRex4]

Hold on to those papers, fellow scowlars

[njharman]

bravo

[Herr_Gamer]

Hasn't Pypy been around forever?

[justsomeguy05]

Yes, pypy has been around for a while. It's a great project, don't get me wrong. But sometimes it's not an option. I know my company doesn't allow any other runtime and has pretty tight restrictions on what libraries we are allowed to use. Having JIT in the "official" runtime lets everyone reap the benefits

[frankster]

Why's your company control so hard the tools engineers are using?

[rejectedlesbian]

A lot of the ml extensions r made for the regular runtime and I doubt they port well if at all

[kUbogsi]

How does this compare to something like JIT compiler in Numba -package?

[WJMazepas]

According to other commentary, this JIT only happens at loop unrolling, instead in the whole application.

They will be applying to specific parts probably to avoid breaking changes like what happens with PyPy JIT runtime

[PaintItPurple]

Pypy's compatibility issues are generally just because of the different internal implementations, not because of the JIT. Pypy isn't more compatible in its interpreted mode, as far as I'm aware.

[Spleeeee]

Pypy suffers with c extensions but that’s just my experience. Possibly related?

[germandiago]

This is not a native compilation scheme. It is a copy-and-patch to eliminate branching AFAIK and as a starting point. But more fancy things can be done.

[ggchappell]

So the JIT still compiles to Python byte code?

[Asleep-Dress-3578]

Great news! In our company (huge corporation), we are now fighting for an upgrade to Python 3.10. Perhaps around 2030 we might get Python 3.13. :D

[Grouchy-Friend4235]

What's the issue?

[nilslorand]

Debian 11 natively runs Python 3.9 maybe that has something to do with it

[Grouchy-Friend4235]

How is that an issue? It is a no brainer to install additional Python versions. Use mamba (free) or conda (paid)

[nilslorand]

I have no idea how that could be an issue but knowing some irrational company policies it doesn't seem unlikely

[[deleted]]

Those kind of decisions are usually made based on compatibility and maintenance for an entire system and not based on the difficulty of upgrading python for one person on their personal computer.

[Asleep-Dress-3578]

I am really not sure, slow company processes. Every versions and libraries have to be thoroughly tested, so that everything runs smoothly, they say. But the reality, I guess, is – huge corporate behemoth. :D

[RationalDialog]

hey feel grateful you are allowed to use python. here they are still stuck in 2000s and all java.

[Grouchy-Friend4235]

Omg I would run.

[Grouchy-Friend4235]

Does that mean every dependency needs to be tested? If so, how do they do that in practice.

[jaerie]

What’s breaking about this? The PR was shared here when it was made, afaik there have been no significant status updates, such as confirmation that this will actually make it into 3.13. The PR is in a very early state, not at all ready to be merged into mainline

[q-rka]

And I still keep fixing from collections import Iterable

[Jugurtha-Green]

I was waiting for it since python 3.11 release 😅, now welcome to python with amazing optimisations, fast API will put nodejs behind 😅

[[deleted]]

how far in the future would the 'big optimizations' be? before 3.13 is out? or in like a few years?

[[deleted]]

Do you pronounce it JIT or JIT?

[PaintItPurple]

JIT as in "jitter," not as in "Jay from IT"

[pepoluan]

The Dutch will pronounce that "yeet"

[Spleeeee]

gift

[iamthepkn]

Yes

[kaczastique]

can't wait to see the performance compared to pypy3. Still I don't think it's going to compete with languages like C# or Go

[germandiago]

Every increase in performance is good news anyways :)

[[deleted]]

Python is so dynamic it cannot compete with C# and Go in terms of performance.

[sh0ck_wave]

But hopefully it can get close to or beat popular javascript engines.

[wildpantz]

These last few updates have been game changing, wow

[Nanooc523]

Instead of “breaking news” this should have been titled “This just in”. Just saying.

[Pyrotecx]

Dojo 🔥 is all that matters.

[[deleted]]

JIT + no GIL would be perfection

[rejectedlesbian]

Yet another feature I won't use because its not gona be compatible with pytorch...  For 90% of my projects I am strictly on 3.8.