[issue44791] Substitution of ParamSpec in Concatenate
Mehdi2277 added the comment:
Concatenate[int, ...] I would interpret as a function signature with first
argument int, followed by arbitrary arguments afterwards. I haven't run into
this case, but ... is allowed in other spots Paramspec is allowed currently.
P = Paramspec("P")
class Foo(Generic[P]):
...
Foo[...] # Allowed
Callable[..., None] # Allowed
Are there any other places a paramspec is allowed? Generic type argument, first
argument to callable, last to concatenate, anything else?
I'm unaware of any type checking use case for Concatenate[int, ...]. You can
practically get same thing by using a paramspec variable without using it
elsewhere so that it captures, but then effectively discards that information.
def use_func1(f: Callable[Concatenate[int, P], None]) -> None:
...
def use_func2(f: Callable[Concatenate[int, ...], None]) -> None:
...
feels like those two signatures should encode same information.
--
nosy: +med2277
___
Python tracker
<https://bugs.python.org/issue44791>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46743] Enable usage of object.__orig_class__ in __init__
Mehdi2277 added the comment: Hmm, I actually have code that does something very similar to that. But it does not set it in `__init__` and instead uses it in a property where it is available. Tweaking your code, ```py class DefaultBox(Generic[T]): def __init__(self, value: T | None = None): self._default_value = value self._value_set = False @property def value(self) -> T: if not self._value_set: self._value = self._default_value if self._default_value is not None else self.__orig_class__.__args__[0]() return self._value ``` I think should work fine. Any reason initializing value afterwards is an issue? Or is the main goal that the original code is simpler then this lazy initialization workaround. -- nosy: +med2277 ___ Python tracker <https://bugs.python.org/issue46743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45384] Accept Final as indicating ClassVar for dataclass
Mehdi2277 added the comment: I recently hit this issue working on a config/parsing runtime type checking library (similar in spirit to pydantic). The one other special typeform I was using these with that led me to discover this issue was Annotated. I use Annotated a fair amount to do some runtime analysis and I was used to `Annotated[typeform]` always works. But ClassVar and Final are special and `Annotated[ClassVar[...]] `and `Annotated[Final[...]]` both fail. I find `Annotated` interaction also weird. I ended up working around it by doing `ClassVar[Annotated[...]]` and stripping the classvar/final to look for the annotation metadata. I think all 3 of annotated/final/classvar should be order compatible as they all serve to add information on the type they contain. If we ignore Annotated, I would say ClassVar/Final should be order compatible and a rule that Final[ClassVar[...]] works but not ClassVar[Final[...]] or vice versa would be weird. -- nosy: +med2277 ___ Python tracker <https://bugs.python.org/issue45384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Change by Mehdi2277 : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue46195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
New submission from Mehdi2277 :
This is two closely related issues with get_type_hints on an optional annotated
member. I'm testing with Annotated/get_type_hints from typing extensions on 3.8
and assuming they're backport equivalent to current behavior.
The first issue is get_type_hints has inconsistent behavior depending on
whether annotation comes from a function with a None default or an attribute
with a None default.
class Foo:
def __init__(
self,
x:
Annotated[Optional[str], "doc string"] = None,
):
...
class Foo2:
x: Annotated[Optional[str], "doc string"] = None
get_type_hints(Foo.__init__)
# {'x': typing.Union[typing_extensions.Annotated[typing.Union[str, NoneType],
'doc string'], NoneType]}
get_type_hints(Foo2)
# {'x': typing_extensions.Annotated[typing.Union[str, NoneType], 'doc string']}
Attributes with a None default are not wrapped by get_type_hints, but function
parameters. Which of the two behaviors is correct I don't know, but I'd expect
the two to be equivalent annotations.
The second issue is for function arguments with a None default the optional
wrapper happens even if the type inside annotated already has optional. Example,
from typing_extensions import Annotated, get_type_hints
class Foo:
def __init__(
self,
x:
Annotated[Optional[str], "doc string"] = None,
):
...
get_type_hints(Foo.__init__, include_extras=True)
# {'x': typing.Union[typing_extensions.Annotated[typing.Union[str, NoneType],
'doc string'], NoneType]}
For Annotated types I would expect any type rules like wrapping to apply only
to the first argument and not the entire annotation. I mainly ran into this for
a runtime type introspection library (similar in spirit to pydantic).
As a note include_extras being True or False while it changes type is an issue
in either case. With include_extras as False the Annotated goes away, but the
type still gets double wrapped as an Optional.
--
messages: 409319
nosy: gvanrossum, kj, med2277
priority: normal
severity: normal
status: open
title: Annotated and Optional get_type_hints buggy interaction
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue46195>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
