Joseph Perez added the comment:
There is also https://bugs.python.org/issue44293 about inspect.isclass
--
nosy: +joperez
___
Python tracker
<https://bugs.python.org/issue45
Joseph Perez added the comment:
Indeed, sorry, my example was bad. My library was raising at several place, and
I've extrapolated about generic substitution.
I've indeed other substitutions (without `TypeVar`), and because they were
failing, I've assumed that all of my substitutions were
New submission from Joseph Perez :
`types.UnionType` is not subscriptable, and this is an issue when type
manipulations are done.
A common maniputation I've to do is to substitute all the `TypeVar` of a
potential generic type by their specialization in the given context.
For example, given
New submission from Joseph Perez :
`typing.NewType` doesn't support PEP 604.
```
>>> import typing
>>> A = typing.NewType("A", int)
>>> B = typing.NewType("B", str)
>>> A | B
Traceback (most recent call last):
File "", l
Joseph Perez added the comment:
@Jelle Zijlstra Thank you for the explanation.
> The current implementation of GenericAlias has been around for a few releases
> by now, though, so that change might break some use cases.
I agree that a "fix" could have unexpected side-effect
New submission from Joseph Perez :
PEP 585 has the side-effect of making `list[int]` an instance of `type`. This
is not the case for other generic aliases.
It also implies that `inspect.isclass(list[int]) is True`, while `list[int]` is
not a class; as a proof of this statement `issubclass
New submission from Joseph Perez :
`typing.get_type_hints` gives a different result for a wrapper created with
`functools.wraps` in case of inferred `Optional` arguments (when the default
value of the argument is None)
```python
from functools import wraps
from typing import get_type_hints
Joseph Perez added the comment:
That's why it's not an interpreter issue but a lack in the official
documentation where the signature is documented.
I quote https://docs.python.org/3/library/functions.html#type:
> class type(object)
> class type(name, bases, dict)
The second line
New submission from Joseph Perez :
Class definition can have kwargs which are used by `__init_subclass__` (and
`__prepare__`).
However, passing these kwargs using `type` builtin function instead of class
definition syntax is not documented; kwargs are not mentioned in the function
signature
Joseph Perez added the comment:
However, PEP 563 will not solve the recursive type alias issue like `A =
list["A"]` but this is a minor concern.
--
___
Python tracker
<https://bugs.python.o
New submission from Joseph Perez :
PEP 585 current implementation (3.10.0a0) differs from current Generic
implementation about ForwardRef, as illustrated bellow:
```python
from dataclasses import dataclass, field
from typing import get_type_hints, List, ForwardRef
@dataclass
class Node
Joseph Perez added the comment:
Ok, I admit that I did not think about recursive type when proposing this "fix".
I've tried an implementation that just stop when recursion is encountered in a
PR.
--
___
Python tracker
<https://bu
Change by Joseph Perez :
--
keywords: +patch
pull_requests: +20699
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21553
___
Python tracker
<https://bugs.python.org/issu
New submission from Joseph Perez :
(This issue is already broached in https://bugs.python.org/issue38605, and a in
some way in https://bugs.python.org/issue35834, but only as a secondary
subject, that's why I've opened a ticket on this particular issue)
ForwardRef of ForwardRef
14 matches
Mail list logo
