[issue47068] Improve __repr__ of TypeVar
New submission from Kaleb Barrett :
Currently the __repr__ for TypeVar includes the variance information and the
type name (for example ~T, +T_co, -T_contra), but it does not contain bound or
constraint information. I'm not sure what value including variance but not
bound information in the __repr__ is, both are important for the use of
interfaces that use that variable.
I propose we add the bound and constraint information to the __repr__. The
__repr__ is arbitrary as popular type checking tools, such as mypy, and
documentation tools, such as Sphinx, do not use the standard __repr__. Nor is
the __repr__ eval()-able like many builtin types. And for documentation tools
that do use the standard __repr__, this improvement will be propagated to those
tools. (I originally requested this improvement in pdoc which uses the standard
__repr__; the maintainer agreed with this improvement.)
Bounds can be represented using an ASCII representation of the subset operator
"<=" and then the bound. Constraints can be represented using "<=" with a tuple
of the constraints. Perhaps spaces should be added around the "<=" operator? I
have no opinion.
Some examples of the proposed __repr__:
>>> TypeVar("T")
~T
>>> IntT = TypeVar("IntT", bound=int)
>>> IntT
~IntT<=int
>>> TypeVar("AnyStr", str, bytes)
~AnyStr<=(str, bytes)
>>> List[IntT]
List[~IntT<=int]
--
messages: 415562
nosy: ktbarrett
priority: normal
severity: normal
status: open
title: Improve __repr__ of TypeVar
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue47068>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44529] Using typing.Union in isinstance checks
Kaleb Barrett added the comment: Ah, this was implemented for 3.10 as a part of PEP 604. https://www.python.org/dev/peps/pep-0604/#isinstance-and-issubclass. Feel free to close. -- ___ Python tracker <https://bugs.python.org/issue44529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44373] make Event an Awaitable
Change by Kaleb Barrett : -- title: make Event and Awaitable -> make Event an Awaitable ___ Python tracker <https://bugs.python.org/issue44373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44529] Using typing.Union in isinstance checks
New submission from Kaleb Barrett : I have type aliases of Unions like so: Request = Union[WriteRequest, ReadRequest] I'd like to be able to use "Request" in an isinstance check rather than having to duplicate the information in a tuple to pass to the check. Currently I get: TypeError: Subscripted generics cannot be used with class and instance checks Seems like Unions could be used here interchangeably with tuples since they mean the same thing in this context. Of course this would only work if the element types are being capable of being used in isinstance checks. -- messages: 396658 nosy: ktbarrett priority: normal severity: normal status: open title: Using typing.Union in isinstance checks type: enhancement ___ Python tracker <https://bugs.python.org/issue44529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44373] make Event and Awaitable
New submission from Kaleb Barrett : Following on from https://bugs.python.org/issue33544. I don't agree with the original suggestion to deprecate the wait() method on Events, but I do agree that Event should be made Awaitable. Doing so would make code more expressive, but more importantly improve the ability to use Events with generic code that can already handles the other Awaitable types in asyncio. There were generally neutral takes on providing both __await__ and wait, besides Yury Selivanov who implied it was complex (???). I just tried the below, but maybe I'm missing something? class AwaitableEvent(Awaitable[None], Event): def __await__(self) -> None: yield from self.wait().__await__() __iter__ = __await__ -- components: asyncio messages: 395511 nosy: asvetlov, ktbarrett, yselivanov priority: normal severity: normal status: open title: make Event and Awaitable versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43836] range.index doesn't support start/stop optional arguments
Kaleb Barrett added the comment: And so it is... There is also a PR open with a solution from 2017. https://github.com/python/cpython/pull/4378/files. Can this get reviewed? The rationalizations against solving this bug stated in the original issue are weak, range.index *is* useful. I use range objects to describe alternate indexing schemes for an array type (to model HDL datatypes that allow arbitrary indexing schemes). range.index is used to translate user supplied indexes into 0-based indexes to index into a parallel list with the array values. https://github.com/cocotb/cocotb/pull/2510/files#diff-62a4545e5bbb9291f2bdb820609b2d68c69cbafe64faea83beb380d01c02fb5aR315-R319 Additionally, this causes issues with mypy. If you subclass Sequence, mypy will complain if you don't have the optional start and stop arguments in the index method. I would need to feed them into a range object in my implementation. I guess in my case I'm expected to just reject them? This breaks substitutability in my class. It also breaks substitutability with list, tuples, every built-in Sequence type as well. -- ___ Python tracker <https://bugs.python.org/issue43836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43836] range.index doesn't support start/stop optional arguments
New submission from Kaleb Barrett : The range builtin type is a collections.abc.Sequence, which in Python 3.5 added the optional start and stop arguments to the index method of Sequences. However, range.index does not support these optional arguments required by Sequence. I noticed this when creating a wrapper type around range which was a Sequence. mypy complained 'Signature of "index" incompatible with supertype "Sequence"', but attempting to pass the values raised 'TypeError: index() takes exactly one argument (3 given)'. -- components: Library (Lib) messages: 391029 nosy: ktbarrett priority: normal severity: normal status: open title: range.index doesn't support start/stop optional arguments type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42711] lru_cache and NotImplemented
New submission from Kaleb Barrett : Having to return `NotImplemented` (which counts as a successful function call) in `functools.lru_cache` and `functools.cache` decorated binary dunder methods has the potential to fill the LRU cache with calls that will in ultimately result in errors (read "garbage"). There are a few ways to avoid this IMO: 1. Change `functools.lru_cache` not cache calls that result in `NotImplemented`. 2. Allow a user to easily extend `functools.lru_cache` (the implementation is not extensible right now) to do the previously mentioned operation. 3. Add the ability to *throw* `NotImplemented` in binary dunder methods so the function call does not complete. This would work exactly like returning `NotImplemented` and be handled by the runtime. And my current solution... 4. Copy-paste `functools.lru_cache` and add in changes for solution 1 :) -- components: Library (Lib) messages: 383573 nosy: ktbarrett priority: normal severity: normal status: open title: lru_cache and NotImplemented type: performance versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
