Gobot1234 added the comment:
I was just looking through the git diff for this PR and found a bug in this
https://github.com/python/cpython/pull/30887/files#diff-2828caacf5c85c7bd6023ea0e4a381cc5c65179a9822398534c5e9ad9ccbd90dR73.
There's a missing f on the io __getattr__'s message
Gobot1234 added the comment:
> Which classes? Every class that inherits from Generic? That would be
> problematic -- we don't want the addition of typing information to change the
> behavior of a construct (or at least as little as possible).
The class itself would remain
Gobot1234 added the comment:
On the general class instanciation point would there be anything wrong with
just adding a big red warning saying (on the non-existent) docs for these
classes that they don't follow normal class initization or is this too
insignificant of an issue to bother?
>
Gobot1234 added the comment:
```py
class DefaultBox(Generic[T]):
def __init__(self, value: T | None = None):
self.value = (
value if value is not None else # the arg
self.__orig_class__.__args__[0]() # or the default for the type
argument
Gobot1234 added the comment:
Currently I have code that uses the generic argument to a class as the
constructor for its `items`
https://github.com/Gobot1234/steam.py/blob/f99cb77d58b552f1d493663e7b3455f94977347e/steam/trade.py#L380.
As this is called from `BaseInventory.__init__
New submission from Gobot1234 :
When using `__call__` on a `typing/types.GenericAlias` `__orig_class__` is set
to the `GenericAlias` instance, however currently the mechanism for this does
not allow the `__origin__` to access the `GenericAlias` from
`__origin__.__init__` as it performs
Gobot1234 added the comment:
I also support this change. I've had to write a lot of code to make
SpecialForms able to accept my types where the code has to look like:
```py
class Something:
...
def __call__(self, *args, **kwargs):
raise NotImplementedError
```
I also know
Change by Gobot1234 :
--
keywords: +patch
pull_requests: +29103
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30924
___
Python tracker
<https://bugs.python.org/issu
New submission from Gobot1234 :
See [PEP 673](https://www.python.org/dev/peps/pep-0673)
I'm planning to implement this in cpython some point today.
--
components: Library (Lib)
messages: 411736
nosy: Gobot1234, Jelle Zijlstra, gvanrossum, kj
priority: normal
severity: normal
status
Gobot1234 added the comment:
> Do you have evidence that people make this particular mistake often? And that
> the suggested solution is indeed what they should use? Why would you want to
> subclass UserId?
I was just trying to implement something that I thought had a non-obvi
Change by Gobot1234 :
--
keywords: +patch
pull_requests: +28485
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30268
___
Python tracker
<https://bugs.python.org/issu
Gobot1234 added the comment:
> Protocol class is not supported by IDEs for type hints, completions, bug
> findings, etc.
I think most good modern IDEs support using Protocols as type hints, offer
completions on them and help you to find bugs with static analysis. That was
one of th
New submission from Gobot1234 :
I'd like to propose making the error message when subclassing typing.NewType
much more understandable. Currently it looks like:
```
TypeError: NewType.__init__() takes 3 positional arguments but 4 were given
```
But I think we could do much better by adding
New submission from Gobot1234 :
Small snippet to reproduce:
```
from dataclasses import dataclass, field
@dataclass
class Foo:
bool: bool = field()
```
Raises
```
---
RecursionErrorTraceback
New submission from Gobot1234 :
Using asyncio.wait_for and asyncio.all_tasks in combination causes a stack
overflow error.
Code to reproduce issue:
```
import asyncio
async def func():
return asyncio.all_tasks()
async def main():
print(await asyncio.wait_for(func(), timeout=10
15 matches
Mail list logo
