"Operations with arbitrary str keys (instead of string literals or other expressions with known string values) should generally be rejected. This involves both destructive operations such as setting an item and read-only operations such as subscription expressions. As an exception to the above rule, d.get(e) and e in d should be allowed for TypedDict objects, for an arbitrary expression e with type str. The motivation is that these are safe and can be useful for introspecting TypedDict objects."
get and known, but if it’s not known, it should return Any (or at the very least, the second part of the get or None)
from typing import Union, TypedDict
def func(arg: Union[str, int]):
print(arg)
class Type(TypedDict, total=False):
a: str
b: int
c = Type({"a": "a", "b": 2})
for val in c.values():
func(val)
2 replies
asynccontextmanager. I think I found a bug with it. Not sure whether its issue should go into mypy or typeshed's repository though. And... it is also certainly possible that I have missed something obvious and it is not a bug.
Hello the community,
I just posted a question on StackOverflow: Generic types lose their Generic[T, …] base class in the .pyi file generated by stubgen. And I pasted the question here and any hint would be appreciated. :-)
Let's say here is a very simple class that represents a generic stack and hence is inherited from Generic[T] (§1).
from typing import TypeVar, Generic, List
T = TypeVar('T')
class Stack(Generic[T]): #1
def __init__(self) -> None:
self.items: List[T] = []
def push(self, item: T) -> None:
self.items.append(item)
def pop(self) -> T:
return self.items.pop()
def empty(self) -> bool:
return not self.itemsAnd then let's generate a stub file .pyi for the module in which the Stack class lies, say, stack.py:
$ stubgen stack.py --output stubsIt's obvious that the Generic[T] base class was unexpectedly stripped off (§2). Meanwhile, the type hint for the items property was replaced as Any (§3). Additionally, what makes things more weird is that the stubbed versions of both push and pop still bore the type hint T for the parameter and the return value respectively (§4 and §5).
from typing import Any, TypeVar
T = TypeVar('T')
class Stack: #2
items: Any = ... #3
def __init__(self) -> None: ...
def push(self, item: T) -> None: ... #4
def pop(self) -> T: ... #5
def empty(self) -> bool: ...What happened during the generation of the stub? Is there any explanation to justify such a behavior?
P.S. My mypy version is 0.790.
List[Union[str, int, float, bool]], however when I use it with an argument typed as List[str] I get the following errors:Argument "literal" to "LITERAL" of "ATTR" has incompatible type "List[str]"; expected "List[Union[str, int, float, bool]]"mypy(error)
"List" is invariant -- see http://mypy.readthedocs.io/en/latest/common_issues.html#variancemypy(note)
Consider using "Sequence" instead, which is covariantmypy(note)
mypy is anyone aware of a way to make it "assume" certain custom built-ins? I would like to use it to type-check some scripts for VFX applications (Nuke, Blender, etc) which have their own built-in functions and objects. I'd like to see if I can write stubs for those, but I also would need mypy to "assume" that they have already been imported.
fusion which does not need to be imported in your scripts; I need mypy to know that it's already available without being explicitly imported.
can I define a type as the result value of a function?
I am in this situation: I am using a library that "do stuff" on import. A way to "shut it" is to define an environmental variable before, and I want to do it specifically during the run of the unit tests.
I was thinking to factor it in a importlib.import_module "wrapper", so I would have
from package.module import Class
def foo(obj: Class) -> None: ...in "normal" normal code, and
from testsupport import my_import_function
Class = my_import_function('package.module', 'Class') # this will internally do the "import dance"
def mock_class_obj() -> Class:
mock_class_obj = unittest.mock.create_autospec(spec=Class, instance=True)
# set up behavior...
return mock_class_objunfortunately I don't get how to write the my_import_function return type... I was thinking something like
def my_import_function(name: str, class_name: str) -> typing.Type[typing.Any]:
module = importlib.import_module(name, package)
return typing.cast(typing.Type[typing.Any], getattr(module, class_name))and "it works", but then I have the error error: Variable "mocks.C" is not valid as a type at the signature of mock_class_obj
2 replies
Hey there. Question about Python typechecking: what tool should I use to check the types of classes with dynamically created methods?
Let us say we have a Client class that is dynamically created with methods like this:
>>> client = Client(open_api_spec)
# Dynamically created method with dynamically added annotations
>>> client.get_example.__annotations__
{'return': MySchemaClass}What tool should I use to analyse my code?
I could possibly solve this using code generation, where I would create a Client class with all of the methods and annotations as part of a pre-build step.
But code generation is a can of worms.
Dict[str, str] be compatible with an argument that expects a function returning a Dict[str, Union[str, int]? Here's the full code example:from typing import Callable, Dict, Union
class Foo:
def __init__(self, bar_fn: Callable[[int], Dict[str, Union[str, int]]]):
self.bar_fn = bar_fn
def get_dict(self) -> Dict[str, Union[str, int]]:
return self.bar_fn(1)
def fn_1(x: int) -> Dict[str, Union[str, int]]:
return {"key1": "value1", "key2": 2}
Foo(bar_fn=fn_1) # This works
def fn_2(x: int) -> Dict[str, str]:
return {"key": "value"}
Foo(bar_fn=fn_2) # This raises the following mypy error:
# [filename].py:23: error: Argument "bar_fn" to "Foo" has incompatible type "Callable[[int], Dict[str, str]]"; expected "Callable[[int], Dict[str, Union[str, int]]]"
None and trio-stubs doesn't have that parameter hinted as Optional. https://github.com/python-trio/trio/blob/d203b30f807e43dc9b101de2e52355ebd10b757a/trio/_core/_run.py#L1942 -- https://github.com/python-trio/trio-typing/blob/f32f17b0f242daf2d42407f383ca581d64b6c299/trio-stubs/lowlevel.pyi#L97 i guessed that maybe stubtest would catch this, but it doesn't seem to. is there another approach i should use to find similar cases? or perhaps there is a reason this "can't" be done?
https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-no-implicit-optional
Is this not what you need?
trio has a parameter defaulted to
Noneand trio-stubs doesn't have that parameter hinted asOptional
In this context, would the problem be in trio, or in trio-stubs?
defaults would lose its typing when used in inherited class? This only applies to an attribute with the name defaults.
=None and the stubs have : trio.abc.Clock = .... seems like it would be good to have some tool or another able to find this discrepancy.
mypy.nodes.TypeInfo
6 replies