Perhaps I do know why, and I also know that compiling arbitrary Python to native code still won’t be possible even with type information.
Or maybe you just want to use Python syntax to write C-like code, in which case type hints still aren’t the right tool for the job (maybe look at Cython instead).
You can take a look at the Cython 3. For your information it proceed quite good with type hints only. And I am not saying about the arbitrary Python code. My initial post have the link to an article, but it seems nobody here never read this article. And, for your information, many of programmers that use Python would be happy to have a bit less of the functionality the Python have, to have actual JIT or AOT, not the fictional JIT as in Python 3.13 - 3.14.
I assume by this you’re referring to the content of the article you linked. But how exactly do you recommend fixing it? Python is an interpreted language, not a machine-code-compiled one, so any compiled language derived from Python has to make choices about which features to omit. Those choices will be different based on the tool, so I don’t really see how a central feature within Python itself could adequately express the same concept across those tools.
Okay, you seem to have your mind already made up, and I don’t think there’s any point in my discussing this further with you. Do whatever’s right for you, figure out type hints that’ll make you happy, and compile your code to native. If that works for you, great! It won’t bother any of the rest of us who use more of Python’s features.
That’s to be expected; please don’t be rude about it. “Read this entire article before you engage in this discussion” is a big ask on any discussion board. If you think certain parts of the article are important, mention them on your original post itself. Remember that anyone here has the freedom to just…not interact with this thread. If you want them to make the other choice - to voluntarily have a discussion about your request - your best bet is to present your case for the feature as clearly and succinctly as possible, without relying heavily on users (voluntarily!) navigating to external links.
Communication is hard work . If you think your idea is good, then it should be worth that work. If you don’t think it’s worth the work, you’re always free to back out.
I did read the article - it’s a great breakdown of why static typing alone is not sufficient for compiling Python code. That’s part of why I’m confused, actually - you’ve linked an article detailing why static typing doesn’t solve this problem, but you’re talking about introducing static typing in order to solve the problem. It seems incongruous.
did read the article - it’s a great breakdown of why static typing alone is not sufficient for compiling Python code. That’s part of why I’m confused, actually - you’ve linked an article detailing why static typing doesn’t solve this problem, but you’re talking about introducing static typing in order to solve the problem. It seems incongruous.
“If you want to, you’ll find a way; if you don’t, you’ll find an excuse” As I see it this is an approach of the “professional programmer”.
I can kinda see where you’re coming from here, wanting to unify the more machine level types that different libraries use.
I don’t think that this will necessarily make compilation much easier due to the LSP issue that’s brought up in your linked article, but having a sort of low level typeshed could be useful. Maybe not as raw types, but as some sort of annotated type extension format like the annotated types module created for libraries like Pydantic.
That format allows a lot more information to be passed along to a compiler that would be less easily accessible with just a simple type hint. You would need to handle a lot of common implementation situations though if you wanted those to be generic enough to replace the existing solutions in 3rd party libraries.
. If you think your idea is good, then it should be worth that work. If you don’t think it’s worth the work, you’re always free to back out.