-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
range typing #1304
Comments
Essentially you wish to create 3 new types in that one line. Are there any other languages that support such operations? You can already implement such functionality with |
I presume this is inspired by languages like Ada and Pascal, which allow integer ranges as types. The problem is that usually this requires inserting dynamic checks into the code, e.g. if we have
we can't really say much about whether x is still in range at the end unless we aggressively check the range upon each assignment. I don't think we should do this, because Python's static type checkers (e.g. mypy) don't have the ability to insert range checks (as they only check the code and don't compile it). |
Instead of creating new classes as @Godwhitelight suggested, I propose adding Here are some basic examples:
The problem with this is that it doesn't handle exclusive ranges. The best way I can think of to support them is to use strings to describe the range, for example I don't think the inability of static type checkers to handle all cases should block the implementation of this feature. It seems to me that the worst that can happen is developers having to make changes to type annotations to silence the type checker. |
@Changaco Even though your proposal has a more interesting notation, I do not see how it solves the issue that Guido has mentioned. I think that before hardcoding such things into the language, we should first expand the type system to allow for such complex types. I.e. Type intersections, higher kinded types, etc. Because once we have those, the range thing might even be possible without hardcoding it into the language. |
I agree, this would be nearly impossible to check statically. Static checks would be limited to literals, constants, and perhaps a few more elaborate cases. However, part of the point of type hints is for in-code documentation, so this idea has merit on this point alone. A type checker for range types as suggested here could produce 3 results:
Static checkers (such as mypy) could have options on how to treat indeterminate values in ranges: pass (ignore), warn, fail. A tool/framework like pydantic could use this information to do runtime checks on the values. Saves the boilerplate validation code. Having written all of this... I can see how implementing this could get really complicated really fast. I like the idea, I don't think it should be dismissed because it's difficult. Maybe not a high priority, but still worth considering. I like @Changaco's suggestion for notation, BTW. Another possibility could be to use the
|
Pydantc is already capable of range checking so the code the author requested is achievable with: from pydantic import Field, validate_arguments
@validate_arguments
def example(range_example: int = Field(gt=1, lt=5), min_example: int = Field(ge=5), max_example: float = Field(le=5.4)):
pass |
@jp-larose to achieve that syntax, you can use pydantic and tips from this article: The author of this article has created a special range checker too. |
Also interested in this! Here's an issue I posted yesterday:
|
Let's go through the problems you are trying to solve.
Which ORM are we talking about? Without ORM, you would just define these things as strings in pure SQL. And any ORM has full power to implement such syntax using a few custom typehints.
Python does not have integer promotions. Python types are kept intentionally simple. We are not C, and it's good! Because python is made for a different purpose: for prototyping, for gluing lower-level languages, for building large things quickly.
I feel like if you are using numpy, then it makes a lot of sense to import numpy. I am not a data scienting or a data engineer so I am out of context here. I tried to google these imports and found no mentions of them anywhere. Are you sure it's an actual problem?
I don't think it was ever the case. Pushing libraries into CPython is not a great idea -- it is good for them to be separate. For example, because library authors might not want to match Python's slow release schedule. Or library authors would like to introduce a language like rust or go into their code base. Or they would like to do major breaking changes at some point. None of these changes are possible once a library becomes a part of CPython. Besides adding a library to CPython is hard, especially a large one like numpy. But you are talking about adding a bunch of globals (like int32) from there too. Adding globals is even harder. Imagine someone who does fastapi or django 100% of their time. Will they ever need numpy? Probably not :) |
Yes, but there is no standardisation here. With type hints, these layers are starting to coalesce on that syntax. But without standard more-specific types, the syntax becomes custom [a DSL] at this point.
Plenty of implementations are trying to push Python into a faster direction, including newer versions of cpython, Mojo, LPython, &etc. My thinking is that if the language has the right primitives, then different runtimes can optimise without introducing their own DSL [e.g., cython, Mojo]. So rather than This would open up optimisation opportunities, and it would also improve compatibility (for FFI and networking purposes).
Not really. A non-exhaustive list of examples:
Not so sure about that. Both allow you to define structures, which often go all the way down to the user. Form validation might include restrictions on text length; database columns can have restriction on integer precision; &etc. |
I am afraid it's a super rare case when CPython gets some syntax strictly for other libraries. Yes, there's https://peps.python.org/pep-0646/, but that one is useful everywhere in python. Variadic generics are a useful feature even without touching any libraries. Besides: without variadic generics, it was impossible to express some ideas in Python. It's possible to express integer range types as
Speeding python up and adding lower level primitives are two strictly different tasks. When we speed it up, the user and the global scope are unaffected. When you add stuff, you clutter a language. We already have too much stuff going on in Python. I don't think anybody wants to go the direction of C++ where the language has so much stuff that it can overwhelm even experienced devs.
There is an official type annotation for a C integer: It's
It already does. No need for any builtin special syntax.
They already do in every ORM as far as I know :) Which ORM would you like to use this special integer type? |
I suggest you add Range, Min, and Max typing to check if a number is inside a range or something like that.
That would be useful and really nice to have.
The text was updated successfully, but these errors were encountered: