I’d like to discuss the type hinting in Python, namely, about making it close to a typing in statically typed language(s), but without a complication of the language itself. To be more precise, there is a lot of elementary types (for example ones like int32_t, char, int64_t, etc…) that not exist in the standard Python type hinting, but they are heavily used in some useful libraries/frameworks such as ctypes, PyTorch, Cython, Numba, Numpy, etc… You can take a look at a partial list of these libraries/frameworks here: Compiling typed Python | Max Bernstein The point is that every such library uses it’s own type annotation system and that can cause some disorder in type hinting when using more than one of such tools in an application. I think it would be quite helpful to have some type annotation module in Python that could cover the most (if not entire set) of the possible use cases for such tools. I suppose it would be better to make it a separate experimental module, as it was for standard Python type annotations some time ago.
How are you proposing to enforce this? ctypes is obviously part of Python itself but all the rest are external so will do what they want (or have time to).
Cython (and likely some of the others) pre-dates the type annotation system and so some of its behaviour is just historic and can’t easily be modified.
To an extent, a common but not completely user-visible system does exist in the form of the buffer protocol.
To be honest, I don’t understand what you’re proposing. Just adding a bunch of names to somewhere like the typing module, intended to represent C-level types, but not use them anywhere in the stdlib? That seems pointless.
More significantly, the core language doesn’t even have data types equivalent to things like int32_t. So there’s nowhere that these types could be useful except in 3rd party extensions. And if two extensions have different implementations of (say) a 32-bit signed int type for Python, why would you assume that a function typed as f(x: int32_t) could reliably accept both?
In a codebase that uses a variety of tools/libraries that have low level types like int32_t, if there was a function that could reliably accept both, I think the simple solution is to use a type alias union to describe that.
E.g. type int32_t_common = lib1.int32_t | lib2.int32_t
More significantly, the core language doesn’t even have data types equivalent to things like int32_t. So there’s nowhere that these types could be useful except in 3rd party extensions. And if two extensions have different implementations of (say) a 32-bit signed int type for Python, why would you assume that a function typed as f(x: int32_t) could reliably accept both?
Actually the implementation of int32_t defined by a C99 standard. Implementation of some other C types are defined by an IEEE standards, for example implementation of the double type defined by the IEEE 754 standard for binary64 (double-precision) floating-point numbers. It means that all implementations of these types should be at least compatible.
Do the authors of Cython/Numba/Others even want type hints to do this job? Everything that needs rigid type information has already figured out some other way to do it.
Moved this to Help rather than Ideas, as it appears you need help exploring what typing is, what the Python interpreter does, and what the full problem you’re describing encompases. Once you’ve developed your understanding and idea further, then you can post an Idea topic.
You’ve made vague “I think that…” statements, but not actually described a real problem and a concrete solution. Also, if you really think that type hints will allow Python code to be compiled, you’re misunderstanding their purpose, so the move to the Help category seems justified IMO.
If you don’t want to further discuss the matter, that’s up to you.
Then why are you posting on the discussion forum for Python?
If you don’t think the behavior of Python is relevant to an idea about Python… I am confused about how you even perceive this topic.
It’s quite typical for people with new ideas to need to learn more before their idea can be successful. Please try to be receptive to people telling you about things that you don’t know.
I don’t think i need the help with exploring what typing is, and I am definitely not very much interesting with what the Python interpreter does. I also think I’ve described in detail what problem I am interested in. So I can’t accept moving my topic to Help. Thank you for all your time
“Python Help” is the general discussion category for users of the language. The problem with calling it something like “general discussion” is that a lot of newcomers then assume they should ask for help in other sections instead. Moving a topic to “Python Help” is not meant as an indication that you’re seeking assistance, merely that it’s not a strong fit for any of the other more specific categories.
I’m also having a little trouble understanding what you’re suggesting. To clarify: are you recommending that we have something like an int32 abstract base class/protocol/whatever in the standard library, which other libraries can make their types subclasses of?
What is your desired outcome, here? It’s difficult to understand you without a concrete idea of what you’d like the ecosystem to look like and be able to do.
Then what do you mean “proper type information”? What specifically do you consider inadequate about the current one, and what specific remedies do you suggest?
Maybe you could try to shift the focus from the dynamically typed JIT to the statically typed JIT, so that the same code with type info could run either JIT compiled (with type hints) or interpreted? Could you?
Who is “you” here? It sounds like you’re not willing to do the work yourself, and yet you don’t seem to be able to explain what you want well enough for others to understand. This really doesn’t seem like a productive discussion at the moment…
Well, for example int type hint seems to be inadequate for the compiled language, but it’s OK for interpreted one. Actually, you can take a look at how many C/C++ languages have various types of (processor independent) int to have and idea about type hints (type information) the compiled language needs. The same can be said about many other type hints in Python. But ctypes seems to be unnecessarily verbose.
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).