New submission from Gregory Beauregard :
Currently, `typing.Annotated` (PEP 593) cannot be used at runtime with
`typing.Final` and `typing.ClassVar` with `Annotated` on the outside:
```
from typing import Annotated, Final
# TypeError: typing.Final[int] is not valid as type argument
var
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29045
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30864
___
Python tracker
<https://bugs.python.org/issu
New submission from Gregory Beauregard :
In https://bugs.python.org/issue46491 the typing runtime behavior was changed
so that `Annotated[Classvar[...]]` is now valid at runtime in order to
alleviate tension between typing and non-typing annotation space uses.
dataclasses.py should likely
Gregory Beauregard added the comment:
Thanks for getting back so quickly.
Annotated is set up to be 'transparent' by default to `typing.get_type_hints`
so in the case of using `typing.py` it can be made straightforward by chaining
with `typing.get_origin`, I think.
I don
Gregory Beauregard added the comment:
Or rather,
^\s*(?:(?:\w+\s*\.)?\s*Annotated\s*\[)?(?:\s*(\w+)\s*\.)?\s*(\w+)
--
___
Python tracker
<https://bugs.python.org/issue46
New submission from Gregory Beauregard :
Consider the following code on 3.11 main:
```
from typing import Annotated, ClassVar, get_type_hints
class DC:
a: ClassVar[int] = 3
b: ClassVar["int"] = 3
c: "ClassVar[int]" = 3
d: Annotated[ClassVar[int], (2, 5)]
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29105
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30926
___
Python tracker
<https://bugs.python.org/issu
Change by Gregory Beauregard :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue46539>
___
___
Python-bugs-list mailing list
Unsubscrib
Gregory Beauregard added the comment:
typo: the line is `g: Annotated["ClassVar[int]", (2, 5)] = 3` in the code
sample. Somehow I left it at only `(` for the annotation instead of `(2,5)`
--
___
Python tracker
<https://bugs.python.o
Gregory Beauregard added the comment:
I did try the proposed patch in bpo-41370 and verified it didn't resolve the
issue so I'm not certain they strictly overlap, but I also haven't had time to
fully digest the underlying issues in bpo-41370 yet.
I think it does have releva
New submission from Gregory Beauregard :
```
class C:
a: " ClassVar[int]" = 3
get_type_hints(C, globals()) # SyntaxError: Forward reference must be an
expression -- got ' ClassVar[int]'
```
I discovered while investigating the viability of moving dataclasses.py t
New submission from Gregory Beauregard :
```
class C:
a: "ClassVar"
get_type_hints(C, globals()) # TypeError: Plain typing.ClassVar is not valid
as type argument
```
A stringified lone ClassVar raises at runtime, but this pattern is tested for
in dataclasses unit tests and u
Gregory Beauregard added the comment:
I think this is needed for moving dataclasses to using typing.py introspection
tools to be viable.
--
___
Python tracker
<https://bugs.python.org/issue46
Change by Gregory Beauregard :
--
nosy: +AlexWaygood, sobolevn -GBeauregard
___
Python tracker
<https://bugs.python.org/issue46553>
___
___
Python-bugs-list m
Change by Gregory Beauregard :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue46553>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Gregory Beauregard :
--
nosy: +GBeauregard
___
Python tracker
<https://bugs.python.org/issue46553>
___
___
Python-bugs-list mailing list
Unsubscribe:
Gregory Beauregard added the comment:
I'm drafting an implementation for the purpose of investigating performance
right now; I will share when ready.
--
___
Python tracker
<https://bugs.python.org/is
Gregory Beauregard added the comment:
It's acceptable to mypy, and pyright added support a few months ago when I made
an issue and Eric Traut discovered this pattern in the wild too.
Some of the other type checkers (pyre) still error I believe. My feeling is
that since this has appar
Gregory Beauregard added the comment:
Hi Eric,
to follow up on https://bugs.python.org/msg411943
I'm currently a bit negative on moving to get_type_hints, even though I got it
working for the test suite. I think your worries with nesting are well placed,
particularly with namespace
Gregory Beauregard added the comment:
I think I miscommunicated my intent with sentence placement. I already posted
the thoughts I referred to; they're just my concluding opinion on the technical
merit of using get_type_hints in dataclasses to solve the Annotated problem:
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29162
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30983
___
Python tracker
<https://bugs.python.org/issu
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29178
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30997
___
Python tracker
<https://bugs.python.org/issu
Gregory Beauregard added the comment:
I had a few style, approach, and testing preference questions, but I decided
they're probably best addressed in a code review so I went ahead and posted the
PR.
--
___
Python tracker
<https://bugs.py
New submission from Gregory Beauregard :
https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/test/test_typing.py#L227-L230
typing's testcases contain the following test to ensure instances of TypeVar
cannot be subclassed:
def test_cannot_subclass_vars
New submission from Gregory Beauregard :
Consider the following.
```
import logging
from typing import Annotated, Callable, ParamSpec, TypeVar
T = TypeVar("T")
P = ParamSpec("P")
def add_logging(f: Callable[P, T]) -> Callable[P, T]:
"""A type-safe
Change by Gregory Beauregard :
--
nosy: +sobolevn
___
Python tracker
<https://bugs.python.org/issue46643>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Gregory Beauregard :
I propose removing the callable() check[1] from typing._type_check. This
restriction is usually met in typeform instances by implementing a __call__
method that raises at runtime[2]. _type_check is called at runtime in a few
disparate locations, such
Gregory Beauregard added the comment:
We can also fix this with my proposal in bpo-46644. I'm okay with either fix
(that or implementing __call__), or both.
--
___
Python tracker
<https://bugs.python.org/is
Gregory Beauregard added the comment:
In addition to the 10 tests failed in test_typing.py, one additional test fails
in test_types.py with this change:
https://github.com/python/cpython/blob/bf95ff91f2c1fc5a57190491f9ccdc63458b089e/Lib/test/test_types.py#L834-L838
and those are all the
Gregory Beauregard added the comment:
The reason this test passed before is a bit confusing. Run the following code
standalone to see where the type(TypeVar('T'))(name, bases, namespace) check is
coming from.
```
class TypeVar:
def __init__(self, name, *constraints):
#
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29324
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31148
___
Python tracker
<https://bugs.python.org/issu
Gregory Beauregard added the comment:
Fixing this test unblocks bpo-46644
--
___
Python tracker
<https://bugs.python.org/issue46642>
___
___
Python-bugs-list m
Change by Gregory Beauregard :
--
nosy: +GBeauregard
nosy_count: 2.0 -> 3.0
pull_requests: +29325
pull_request: https://github.com/python/cpython/pull/31148
___
Python tracker
<https://bugs.python.org/issu
Gregory Beauregard added the comment:
Under the same failing int test cases before there were 2 more cases next to
them that fail:
with self.assertRaises(TypeError):
ClassVar[int, str]
with self.assertRaises(TypeError):
Final[int, str]
These fail because tuple literals are not
Gregory Beauregard added the comment:
Further questions: the msg argument in _type_check now wouldn't be used for
anything! It was only used in the case where a type wasn't callable(). I think
it should be removed. I'm also a bit negative on disallowing tuples in the case
of
Gregory Beauregard added the comment:
I made a draft pull request where I went ahead and added a check to disallow
tuple literals. This is basically already disallowed for types by restrictions
on `__getitem__` because Union[typeform]->type needs to be different from
Union[type,type]->
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29328
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31151
___
Python tracker
<https://bugs.python.org/issu
New submission from Gregory Beauregard :
typing.TypeAlias is allowed to be bare, but it's not listed in the list of
types in typing._type_check that are allowed to be bare. This means it's
possible to reach the wrong error `TypeError: Plain typing.TypeAlias is not
valid as type ar
Change by Gregory Beauregard :
--
nosy: +Jelle Zijlstra
___
Python tracker
<https://bugs.python.org/issue46655>
___
___
Python-bugs-list mailing list
Unsub
Change by Gregory Beauregard :
--
nosy: +kj
___
Python tracker
<https://bugs.python.org/issue46655>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29331
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31156
___
Python tracker
<https://bugs.python.org/issu
Gregory Beauregard added the comment:
The issue in real code I had in mind was internal to cpython: if we remove the
callable() check from _type_check naively, this test starts to fail. Both of
our proposed changes happen to not fail this check. Given your second example,
would you prefer
Gregory Beauregard added the comment:
List[42] is already accepted, and your proposed patch does not change it to
make it not accepted. The issue is _type_check is only called in a few
particular locations; this is part of the technical reason I'm not very
concerned about relaxin
Gregory Beauregard added the comment:
I'm referring to within type annotations, where this code path isn't used: try
a: List[42]
This code path can show up in type aliases though.
--
___
Python tracker
<https://bugs.python.o
Gregory Beauregard added the comment:
I compiled your PR to run it and was testing in 3.10 as well, but I was testing
in a file with from __future__ import annotations unintentionally. I retract
the comment. It turns out `list[42]` is okay though, which I suppose is more
relevant going
Change by Gregory Beauregard :
--
pull_requests: +29346
pull_request: https://github.com/python/cpython/pull/31175
___
Python tracker
<https://bugs.python.org/issue46
New submission from Gregory Beauregard :
from typing import ParamSpec
P = ParamSpec("P")
print(P.args == P.args) # False
print(P.kwargs == P.kwargs) # False
ParamSpec args and kwargs are not equal to themselves; this can cause problems
for unit tests and type introspect
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29373
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31203
___
Python tracker
<https://bugs.python.org/issu
Change by Gregory Beauregard :
--
pull_requests: +29380
pull_request: https://github.com/python/cpython/pull/31210
___
Python tracker
<https://bugs.python.org/issue46
Gregory Beauregard added the comment:
My general understanding has been that since Annotated exists primarily to
allow interoperability between typing and non-typing uses of annotation space,
and that this is quite clear in the PEP, most cases where this is not allowed
(_especially_ at the
Gregory Beauregard added the comment:
I have made a thread on typing-sig to discuss this:
https://mail.python.org/archives/list/typing-...@python.org/thread/WZ4BCFO4VZ7U4CZ4FSDQNFAKPG2KOGCL/
--
___
Python tracker
<https://bugs.python.
Change by Gregory Beauregard :
--
keywords: +patch
pull_requests: +29408
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31238
___
Python tracker
<https://bugs.python.org/issu
Gregory Beauregard added the comment:
I wrote a PR that fixes the underlying issue here, but I'm leaving it as a
draft while the discussion plays out. I think the stuff currently in the patch
should be okay regardless of the discussion decision, because the underlying
issue is that P
Gregory Beauregard added the comment:
It occurred to be that we do need to add the __call__ to KW_ONLY, but for a
different reason than this bpo:
If you call get_type_hints on a dataclass with a KW_ONLY parameter when PEP 563
is enabled, the entire call will fail if KW_ONLY isn't cal
New submission from Gregory Beauregard :
PEP 591 for the Final Attribute states "Type checkers should infer a final
attribute that is initialized in a class body as being a class variable.
Variables should not be annotated with both ClassVar and Final."
This is a bit of a typing co
Change by Gregory Beauregard :
--
type: enhancement -> behavior
___
Python tracker
<https://bugs.python.org/issue45384>
___
___
Python-bugs-list mai
Gregory Beauregard added the comment:
Hi Eric,
I've been shopping this idea around on the mailing list and haven't received
any objections. Do you have any concerns? Can we handle Final with the same
checks as ClassVar?
Regarding potentially merging a change, I'm not sure w
Gregory Beauregard added the comment:
When I originally submitted the issue I hadn't finished going through all of
the dataclasses code and it hadn't even occurred to me that it could be valid
to use ClassVar with field(). I (wrongly) assumed this would always raise and
that field
Gregory Beauregard added the comment:
Yeah, I was just discussing this with someone in IRC, and I appreciate an
example of it in the wild.
I agree there's some wiggle room with what "initialized in a class body" means
when it comes to dataclasses.
I see several interpretatio
Gregory Beauregard added the comment:
Thanks for the feedback Carl.
Your proposed nesting PEP change is not possible: ClassVar[Final[int]] isn't
valid because Final[int] isn't a type. As far as I know this would need type
intersections to be possible.
I'm going to try se
Gregory Beauregard added the comment:
I get no attribute error with this code in 3.9 or 3.10.
--
nosy: +GBeauregard
___
Python tracker
<https://bugs.python.org/issue45
Gregory Beauregard added the comment:
Hi Michael,
Thanks for taking the time to look into this.
I don't feel strongly enough about following the existing PEP wording to desire
creating a situation where instance vars can't be marked Final if we can
instead make a workaround wit
62 matches
Mail list logo
