Bas van Beek added the comment:
All right, the `__name__` bug fix is up at
https://github.com/python/cpython/pull/27614.
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Bas van Beek :
--
pull_requests: +26108
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/27614
___
Python tracker
<https://bugs.python.org/issu
Bas van Beek added the comment:
I do agree that it's nice to have a `__name__` for special forms, as they do
very much behave like types even though they're strictly speaking not distinct
classes.
Whether we should have this feature is a distinct "problem" from its `__
Bas van Beek added the comment:
This PRs herein have created a situation wherein the `__name__`/`__qualname__`
attributes of certain typing objects can be `None`.
Is this behavior intentional?
```
>>> from typing import Union
>>> print(Union[int, float].__name__)
None
``
Bas van Beek added the comment:
> Do any of the other deleted types strike you as possibly needing to come back?
I don't think so, no. The only other one that stands out to me is
`DictProxyType`, which has already been reintroduced as `MappingP
Bas van Beek added the comment:
According to the relevant commit
(https://github.com/python/cpython/commit/c9543e42330e5f339d6419eba6a8c5a61a39aeca):
"Removed all types from the 'types' module that are easily accessible th
Bas van Beek added the comment:
`NoneType` and `NotImplementedType` have been added to the PR as of the latest
set of pushes.
--
___
Python tracker
<https://bugs.python.org/issue41
Bas van Beek added the comment:
Apparently pyright has some interest in `NoneType`
(https://github.com/python/typeshed/pull/4519), so it seems there are already
some actual use cases.
In any case, I'm ok with adding `NoneType` and `NotImplementedType` to t
Bas van Beek added the comment:
If we're going ahead with this: PR https://github.com/python/cpython/pull/22336
contains a concrete implementation of the proposed changes.
--
___
Python tracker
<https://bugs.python.org/is
Change by Bas van Beek :
--
keywords: +patch
pull_requests: +21381
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22336
___
Python tracker
<https://bugs.python.org/issu
Bas van Beek added the comment:
If you're asking whether or not one can infer the return type of
`type(Ellipsis)` then yes.
In such case the inferred type is `builtins.ellipsis`, which is a private
stub-only class (see the referenced typeshed issue in my original post).
If you're
New submission from Bas van Beek :
`Ellipsis` is one of the few builtin objects whose type is not exposed via the
`types` module.
This is not really an issue during runtime, as you can always call
`type(Ellipsis)`, but for the purpose of typing it is detrimental; the lack of
suitable type
12 matches
Mail list logo
