[issue46522] concurrent.futures.__getattr__ raises the wrong AttributeError message
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 -- nosy: +Gobot1234 ___ Python tracker <https://bugs.python.org/issue46522> ___ ___ 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__
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 unchanged, the only thing I propose changing is what happens when you subscript it and then attempt to instantiate it. -- ___ 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
[issue46743] Enable usage of object.__orig_class__ in __init__
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?
> I don't think it's possible in general, since you are blindly instantiating
> the type (self.__orig_class__.__args__[0]) without arguments. That doesn't
> work for all types.
I think you could make this work with a Protocol as the bound TypeVar("T",
bound=HasTheCorrectNewSignature)?
> I'm also not sure what static type checkers would make of this. But I presume
> you don't care about that.
Yeah considering this is only accessed in one place and how likely difficult it
would be to implement it doesn't bother me much no. (You can avoid the
attribute access errors using __orig_class__: GenericAlias if you know what
your doing is always safe).
> Or is the main goal that the original code is simpler then this lazy
> initialization workaround.
Pretty much yeah I'd like the code to be much simplier and avoid this work
around (although you could probably simplify it with a cached_property)
--
___
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
[issue46743] Enable usage of object.__orig_class__ in __init__
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 ) int_box = DefaultBox[int]() print(int_box.value) # should print 0 str_box = DefaultBox[str](value="this") print(str_box.value) # should print this ``` Currently this doesn't work, but I really think it should. -- ___ 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
[issue46743] Enable usage of object.__orig_class__ in __init__
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__` it currently fails if I just subclass `GenericAlias`, so I had to implement `__call__` myself https://github.com/Gobot1234/steam.py/blob/f99cb77d58b552f1d493663e7b3455f94977347e/steam/trade.py#L299-L307. -- ___ 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
[issue46743] Enable usage of object.__orig_class__ in __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 something akin to: ```py def __call__(self, *args, **kwargs): object = self.__origin__(*args, **kwargs) object.__orig_class__ = self return object ``` I'd like to propose changing this to something like: ```py def __call__(self, *args, **kwargs): object = self.__origin__.__new__(*args, **kwargs) object.__orig_class__ = self object.__init__(*args, **kwargs) return object ``` (Ideally `__orig_class__` should also be available in `__new__` but I'm not entirely sure if that's possible) AFAICT this was possible in the typing version back in 3.6 (https://github.com/python/typing/issues/658 and maybe https://github.com/python/typing/issues/519). Was there a reason this was removed? -- components: Library (Lib) messages: 413198 nosy: Gobot1234, gvanrossum, kj priority: normal severity: normal status: open title: Enable usage of object.__orig_class__ in __init__ type: enhancement versions: Python 3.11 ___ 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
[issue46644] typing: remove callable() check from typing._type_check
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 this comes up in typing-extensions a fair bit. I think type checkers should be enforcing this at type-checking-time not by typing.py run-time. -- nosy: +Gobot1234 ___ Python tracker <https://bugs.python.org/issue46644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46534] Implementing PEP 673 (Self type)
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/issue46534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46534] Implementing PEP 673 (Self type)
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: open title: Implementing PEP 673 (Self type) type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46170] Improving the error message when subclassing NewType
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-obvious error message and isn't necessarily initially obvious if you have the idea that NewType creates a new type/class. The documentation suggests this is what you should be doing instead of subclassing it https://github.com/python/cpython/commit/342e800e974475cc302c46ed6d9f75276035278f#diff-8a0f115fde6769c122b771b6d0eca184c4580f7b5fabe2f0b0579c679424364fR101-R113 > Do we have examples of other error messages split across two lines like this? No if you want me to remove it thats fine by me. -- ___ Python tracker <https://bugs.python.org/issue46170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46170] Improving the error message when subclassing NewType
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/issue46170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46174] Feature Request for Python Interfaces
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 the main reasons they were implemented. -- nosy: +Gobot1234 ___ Python tracker <https://bugs.python.org/issue46174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46170] Improving the error message when subclassing NewType
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 __mro_entries__ to the class and
then just having that raise a TypeError telling users they cannot subclass
NewType and they are probably looking for `NewType('Subclass', OlderType)`. I'd
be happy to patch this myself if this sounds like a good idea.
--
components: Library (Lib)
messages: 409114
nosy: Gobot1234, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Improving the error message when subclassing NewType
type: enhancement
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46170>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45946] RecursionError when annotating a field with the same name as a field
New submission from Gobot1234 :
Small snippet to reproduce:
```
from dataclasses import dataclass, field
@dataclass
class Foo:
bool: bool = field()
```
Raises
```
---
RecursionErrorTraceback (most recent call last)
in
2
3 @dataclass
> 4 class Foo:
5 bool: bool = field()
6
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py
in dataclass(cls, init, repr, eq, order, unsafe_hash, frozen, match_args,
kw_only, slots)
1176
1177 # We're called as @dataclass without parens.
-> 1178 return wrap(cls)
1179
1180
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py
in wrap(cls)
1167
1168 def wrap(cls):
-> 1169 return _process_class(cls, init, repr, eq, order, unsafe_hash,
1170 frozen, match_args, kw_only, slots)
1171
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py
in _process_class(cls, init, repr, eq, order, unsafe_hash, frozen, match_args,
kw_only, slots)
1085 # Create a class doc-string.
1086 cls.__doc__ = (cls.__name__ +
-> 1087str(inspect.signature(cls)).replace(' -> None',
''))
1088
1089 if match_args:
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/inspect.py in
__str__(self)
3200 render_kw_only_separator = True
3201 for param in self.parameters.values():
-> 3202 formatted = str(param)
3203
3204 kind = param.kind
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/inspect.py in
__str__(self)
2717 if self._annotation is not _empty:
2718 formatted = '{}: {}'.format(formatted,
-> 2719
formatannotation(self._annotation))
2720
2721 if self._default is not _empty:
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/inspect.py in
formatannotation(annotation, base_module)
1362 return annotation.__qualname__
1363 return annotation.__module__+'.'+annotation.__qualname__
-> 1364 return repr(annotation)
1365
1366 def formatannotationrelativeto(object):
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py
in __repr__(self)
281
282 def __repr__(self):
--> 283 return ('Field('
284 f'name={self.name!r},'
285 f'type={self.type!r},'
... last 1 frames repeated, from the frame below ...
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/dataclasses.py
in __repr__(self)
281
282 def __repr__(self):
--> 283 return ('Field('
284 f'name={self.name!r},'
285 f'type={self.type!r},'
RecursionError: maximum recursion depth exceeded while getting the repr of an
object
```
This is due to the self.type being the field itself as the annotation is
evaluated using the class namespace.
--
components: Library (Lib)
messages: 407438
nosy: Gobot1234, eric.smith
priority: normal
severity: normal
status: open
title: RecursionError when annotating a field with the same name as a field
type: crash
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue45946>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42183] Stack overflow error with asyncio.all_tasks and wait_for
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)) asyncio.run(main()) ``` I'm not too sure how far back this goes but I've managed to reproduce it on sys.version_info(major=3, minor=8, micro=0, releaselevel='final', serial=0) and sys.version_info(major=3, minor=9, micro=0, releaselevel='final', serial=0). -- components: asyncio messages: 379837 nosy: Gobot1234, asvetlov, yselivanov priority: normal severity: normal status: open title: Stack overflow error with asyncio.all_tasks and wait_for versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
