typing.Counter doesn't seem useful, unfortunately.
Counter
MyModel.select(alias=orm.ref('model_field')) where I’d like orm.ref('model_field') to be typed to return Expression[<type of field>]. In my mypy plugin I have the context I need in the get_method_hook for select(), but not in the get_function_hook for orm.ref(). Does anyone know if it’s possible to achieve this in mypy currently, or will I have to manually check everything in the method-callback?
TypedDict for a typed dictionary I have. One thing I don't understand from here is that it has a first argument that is a string. What is that for? Also, in the mypy docs, it is described as being intyping_extensions, but the StackExchange page that pointed me at TypedDict says to use mypy_extensions. Is mypy_extensions just an obsolete name for typing_extensions? Thanks!
NamedTuple from collections works. I believe TypedDict started out in mypy_extensions, then moved to typing_extensions once standardized, and finally to the typing module starting from Python 3.8
TypeInfo objects where I push them in get_method_signature_hook and pop them in get_method_hook, as the get_function_hook calls where I need this context seems to be called between these two callbacks. If this is a Bad idea™️ and anyone has better suggestions I'd love some feedback
aiohttp.ClientSession and add one keyword argument to it's __init__ leaving others as-is. I want to avoid copying whole __init__ type signature from ClientSession. Can I somehow express that Subclass.__init__ is adding one argument to ClientSession.__init__ without changing others?
Hi friends. I've been looking into NewType recently, because I've been using the "builtins as a base class" approach to making subtypes to builtins, and I didn't know NewType existed: https://www.python.org/dev/peps/pep-0484/#newtype-helper-function
From the docs, it says that the motivation for creating NewType is to minimize runtime overhead... should this actually be a concern of mine? Is there some reason that using subclasses of builtins (I know they don't need to be builtins but that's probably the most common use case) causes lots of runtime overhead? It just seems like it would be on par with the builtin itself, in which case it seems like there's not much reason to care about runtime overhead..
I'm having trouble figuring out how to use MYPYPATH...
$ tree demo2/ stubs/
demo2/
└── foo.py
stubs/
└── foo.pyi
0 directories, 2 files$ MYPYPATH="$PWD/stubs" venv/bin/mypy demo2
demo2/foo.py:2: error: Incompatible return value type (got "int", expected "str")
demo2/foo.py:5: error: Incompatible return value type (got "int", expected "str")
Found 2 errors in 1 file (checked 1 source file)$ mv stubs/foo.pyi demo2/
$ venv/bin/mypy demo2
Success: no issues found in 1 source fileWhat am I missing?
Same deal
$ tree demo2 stubs
demo2
└── foo.py
stubs
└── demo2
└── foo.pyi
1 directory, 2 files
$ MYPYPATH="$PWD/stubs" venv/bin/mypy demo2
demo2/foo.py:2: error: Incompatible return value type (got "int", expected "str")
demo2/foo.py:5: error: Incompatible return value type (got "int", expected "str")
Found 2 errors in 1 file (checked 1 source file)Does demo2 or foo.py need to be installed?
__init__.py files in both the dir you're in and the demo2 dir and then try MYPYPATH="./stubs" venv/bin/mypy ., this is the way I usually run it
.pyi files in the same dir as the .py files works)... also the fact that mypy will only check the stub files and not look at the normal .py files at all makes it seem not super useful to me anyway
I often come across a certain pattern in Python, where a subclass defines an inner class for the superclass to use.
The following is an example of how I'd expect to use MyPy alongside that pattern:
from typing import Generic, TypeVar, Type
T = TypeVar("T")
class Request(Generic[T]):
Response: Type[T]
def invoke(self) -> T:
...
# since Response is defined in the body I'd expect MyPy to infer the type parameter (T)
class MyRequest(Request):
class Response:
thing: int
x = MyRequest().invoke().thing
# x should have type `int`(This is a little like type members in languages like Scala)
however, no inference is done. This isn't really a bug, but it makes this pattern somewhat cumbersome to annotate since now we're dealing with a forward reference:
class MyRequest(Request["MyRequest.Response"]):
...There are a bunch of other cases where this sort of inference would be nice.
How crazy would it be to infer T in the first case?