Open
Conversation
…d allow circular imports between files. - added nested dtypes, bytesarray, and memoryview as literal, convertible python types - PythonLiteral is a recursive type, to allow dict of list, list of list, etc...
- _ExpressionLike -> IntoExpr - Expression | str -> IntoExprColumn
…mpy ndarray without creating unknown type errors if the library isn't installed in the venv
…als, not list of Any element
- Using IntoExprColumn on StarExpression - fixed lhs type for LambdaExpression, and value type for ConstantExpression
- fixed all places where it was too narrow. Most of the time str are accepted for sqltypes. odd exception seems to be the map method on Relation - using Self for annotations on arguments when pertinent
…d allow circular imports between files. - added nested dtypes, bytesarray, and memoryview as literal, convertible python types - PythonLiteral is a recursive type, to allow dict of list, list of list, etc...
- _ExpressionLike -> IntoExpr - Expression | str -> IntoExprColumn
…mpy ndarray without creating unknown type errors if the library isn't installed in the venv
…als, not list of Any element
- Using IntoExprColumn on StarExpression - fixed lhs type for LambdaExpression, and value type for ConstantExpression
- fixed all places where it was too narrow. Most of the time str are accepted for sqltypes. odd exception seems to be the map method on Relation - using Self for annotations on arguments when pertinent
…_function and Relation.map
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR provides numerous improvements regarding type hints.
This is my follow-up to our discussion here @evertlammerts:
#341 (comment)
All changes are only in the type stubs, which means that there's no impact whatsoever on any runtime logic.
Changes
_expression.pyifile to separate theExpressionclass, and allow circular imports and references. Leans-up a bit the__init__file, which is nice.Protocolfor numpy array and types. Allow to type check those without emitting errors if the user doesn't have the library installed. Array is useful forExpressionconversions, Dtype forDuckDBPyTypeconversions._ExpressionLiketype alias. Renamed it toIntoExpr, and added various new type aliases covering as much situations as possible forExpressionconversions.strconversions toDuckDBPyType, providing a nice autocompletion for arguments, and a nice interaction with pattern matching when checking the id value.Also, provide
JSONandBIGNUMconvenient instanciation as an added bonus (ATM they are absent from sqltypes constants).DuckDBPyTypeconversions: as python/numpy static type hints, asdictinstances, or asLiteral | str. This significantly improve the types hints regarding datatypes arguments, who were very often only accepting str orDuckDBTypesin the signatures.Literalfor files methods/functions argument options._typing.pyifile, to avoid bloating the__init__.Notes
I tried to document this as best as I could with docstrings for users and "private" comments.
I left a few observations, but what I would add is that one thing is clear, the runtime accepted types are all over the place (sometimes Mapping is ok, sometimes only dict is ok, etc...).
As I said in Typing stubs are too strict about arguments of type
Expression#341 , prioritizingcollections.abcas much as possible would be the best way to go in the future.Centralizing the type aliases and using them as much as possible make sense IMO, especially with an API that have repeated signatures (connexion methods vs module level function for example).
The next step would be to move the type definition in a concrete .py file, allowing user to import those if they want to annotate custom functions or do runtime type introspection.