[issue45578] Missing tests for the dis module
Change by Nikita Sobolev : -- pull_requests: +28278 pull_request: https://github.com/python/cpython/pull/30058 ___ Python tracker <https://bugs.python.org/issue45578> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46005] [doc] replace 'distutils' examples with 'setuptools'
Nikita Sobolev added the comment: Or maybe we should just include https://github.com/python/cpython/blob/main/Doc/distutils/_setuptools_disclaimer.rst as others do? I will send my proposal :) -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46005] [doc] replace 'distutils' examples with 'setuptools'
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28282 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30062 ___ Python tracker <https://bugs.python.org/issue46005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46073] ast.unparse produces: 'FunctionDef' object has no attribute 'lineno' for valid module
Nikita Sobolev added the comment:
Looks like this little patch can solve this problem:
```
def unparse(ast_obj):
unparser = _Unparser()
---return unparser.visit(ast_obj)
+++return unparser.visit(fix_missing_locations(ast_obj))
```
But, I am not sure we should call this helper here.
Another approach is to refactor `get_type_comment` function into something like
this:
```
def get_type_comment(self, node):
comment = None
if hasattr(node, 'lineno'):
comment = self._type_ignores.get(node.lineno)
comment = comment or node.type_comment
if comment is not None:
return f" # type: {comment}"
```
I feel like this is more suitable for this case. Even `ast.pyi` has this line:
```
# TODO: Not all nodes have all of the following attributes
lineno: int
col_offset: int
```
So, I am going to propose a PR with the second option. Please, send your
feedback!
--
nosy: +sobolevn
___
Python tracker
<https://bugs.python.org/issue46073>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46073] ast.unparse produces: 'FunctionDef' object has no attribute 'lineno' for valid module
Nikita Sobolev added the comment: Moreover, there's always an option to pass `lineno` and `column` explicitly: ``` from ast import * # if we build the module manually and try it directly value = Module( body=[ FunctionDef( name="items_needed", args=arguments( posonlyargs=[], args=[], kwonlyargs=[], kw_defaults=[], defaults=[], ), body=[Return(value=Constant(value="test"))], decorator_list=[], lineno=1, column=1, ) ], type_ignores=[], ) unparse(value) # ok ``` -- ___ Python tracker <https://bugs.python.org/issue46073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46073] ast.unparse produces: 'FunctionDef' object has no attribute 'lineno' for valid module
Nikita Sobolev added the comment: Or, maybe this is a correct thing to do. Consider this case. Let's say we now check that `node` has `lineno` and exclude ones that don't. Then, we write this test (in `Lib/test/test_unparse`): ``` def test_unparse_nodes_without_lineno(self): # https://bugs.python.org/issue46073 def create_module(ignores): return ast.Module( body=[ ast.FunctionDef( name="items_needed", args=ast.arguments( posonlyargs=[], args=[], kwonlyargs=[], kw_defaults=[], defaults=[], ), body=[ast.Pass()], decorator_list=[], ), ], type_ignores=ignores, ) ast1 = create_module([]) self.assertASTEqual(ast1, ast.parse(ast.unparse(ast1))) ast2 = create_module([ast.TypeIgnore(lineno=1, tag='')]) # This fill fail without `ast2 = ast.fix_missing_locations(ast2)` self.assertASTEqual(ast2, ast.parse(ast.unparse(ast2), type_comments=True)) ``` In this case the second `assert` will fail, because the resulting codes would be different: ``` # "original" def items_needed(): # type: ignore pass # unparsed def items_needed(): pass ``` So, basically users will get different code. Which is not a good thing. So, maybe raising an error that some `node` does not have `lineno` is good after all? -- ___ Python tracker <https://bugs.python.org/issue46073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46120] Add note to `typing.Union` that it is recommended to use `|` instead
New submission from Nikita Sobolev : As discussed in https://mail.python.org/archives/list/typing-...@python.org/thread/TW5M6XDN7DO346RXMADKBAAGNSZPC4ZQ/ > we could probably stick a huge notice in the typing.Union docs saying `|` is > preferred for readability in most cases, and not deprecate it for now. I will send a PR to `Union` and `Optional` docs with this note today. -- assignee: docs@python components: Documentation messages: 408836 nosy: docs@python, sobolevn priority: normal severity: normal status: open title: Add note to `typing.Union` that it is recommended to use `|` instead type: behavior versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46120] Add note to `typing.Union` that it is recommended to use `|` instead
Change by Nikita Sobolev : -- nosy: +asvetlov, kj ___ Python tracker <https://bugs.python.org/issue46120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46120] Add note to `typing.Union` that it is recommended to use `|` instead
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28443 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30222 ___ Python tracker <https://bugs.python.org/issue46120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
New submission from Nikita Sobolev : Original discussion in `typing` bug tracker: https://github.com/python/typing/issues/985 Short description: - `property[GetType, SetType]` is required for us to remove a lot of special casing from type-checkers and just use the primitive type - In runtime it copies the same behavior `list` / `dict` / other primitive types have under PEP585 Open questions: - I think that it is too late to backport this in 3.10. Am I right? - I hope that `from __future__ import annotations` will just work for this new change. Is there anything I should do in scope of this PR? Is my assumption about `__future__` import is even correct in this context? Do I need to test that it works with `__future__ annotations`? -- components: Library (Lib) messages: 409080 nosy: gvanrossum, kj, sobolevn priority: normal severity: normal status: open title: Make `builtins.property` generic type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Nikita Sobolev added the comment: One more question about PEP585: it does not specify `property`. Do we need to update it? -- ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28460 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30238 ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46150] test_pathlib assumes "fakeuser" does not exist as user
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 1.0 -> 2.0 pull_requests: +28462 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30240 ___ Python tracker <https://bugs.python.org/issue46150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43424] Document the `controller.name` field in `webbrowser` module
Nikita Sobolev added the comment: Hm, looks like `.name` does not exist for `MacOSXOSAScript`: ``` Python 3.11.0a3+ (heads/main-dirty:71ef0b4c2b, Dec 23 2021, 12:38:09) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import webbrowser >>> webbrowser.get() >>> a = webbrowser.get() >>> dir(a) ['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_name', 'args', 'open', 'open_new', 'open_new_tab'] >>> a.name Traceback (most recent call last): File "", line 1, in AttributeError: 'MacOSXOSAScript' object has no attribute 'name'. Did you mean: '_name'? ``` This happens because `MacOSXOSAScript` does not call `super().__init__()` in any way, nor it defines `name` and `basename` attributes. It has this API for 12 years now: https://github.com/python/cpython/commit/4d39f6e09a5c0a0e09eb51d678bacd1adaa3f2ca So, I see two possible ways to solve this: 1. Ensure all subtypes of `BaseBrowser` to have `name` and `basename` (because they are defined in `BaseBrowser`) and document them 2. Add a code comment that they are just implementation details and not a part of the public API -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue43424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43424] Document the `controller.name` field in `webbrowser` module
Change by Nikita Sobolev : -- pull_requests: +28463 pull_request: https://github.com/python/cpython/pull/30241 ___ Python tracker <https://bugs.python.org/issue43424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Nikita Sobolev added the comment:
Thanks, Guido!
> Yes, it is too late for 3.10 (but you can add it to typing_extensions). Also,
> PEP 585 is done, we don't update PEPs.
Got it!
> Please do test with `from __future__ import annotations` -- you never know.
Done, PR is updated. Now we test that `property` works with future import.
> When this was first proposed (https://github.com/python/typing/issues/985)
> there were worries about backwards compatibility. Given how common property
> is, we need to make sure there are no problems with that. Can you address
> that? I don't see it in the original thread.
I guess you were thinking about this one:
https://github.com/python/typing/issues/594
Here's a list of problem from the original thread:
## the returned value of property has no typing equivalent
Now there is: `property[G, S]`
## There is no consistency in how properties in classes work in comparison to
normal variables or functions
Author points out that all python versions right now ignore `property`s when
`get_type_hints()` is used. There's nothing we can do here: it is not related
to `property`s being generic in any way.
Here's how it works before my patch:
```python
Python 3.10.0 (default, Nov 1 2021, 10:24:06) [Clang 11.0.0
(clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from typing import get_type_hints
>>> class Some:
... @property
... def a(self) -> int:
... return 1
...
>>> get_type_hints(Some)
{}
>>> get_type_hints(Some.a)
Traceback (most recent call last):
File "", line 1, in
File "/Users/sobolev/.pyenv/versions/3.10.0/lib/python3.10/typing.py", line
1827, in get_type_hints
raise TypeError('{!r} is not a module, class, method, '
TypeError: is not a module, class, method, or
function.
```
I've added a test case for my patch to make sure this behavior is not changed.
And indeed, it works exactly the same as before.
I've also covered a part from
https://github.com/python/typing/issues/594#issuecomment-627692188
Runtime introspection of `fget` / `fset` / `fdel` works the same as before.
I've added a test case for this.
## Forward compat
Users of python<3.11 will have `property` with `[]` type syntax via
`typing_extensions`.
I don't think it is going to be widely used, though.
> Also, since this requires type checkers to change, do we need a PEP?
I cannot speak for all type-checkers, but I know how it works in mypy. Mypy
already supports descriptors. So, this example works:
```python
class Desc:
def __get__(self, obj, typ) -> int: pass
class Some:
a = Desc()
s = Some()
reveal_type(s.a) # N: Revealed type is "builtins.int"
reveal_type(Some.a) # N: Revealed type is "builtins.int"
```
The same just works for my `property` stub example from
https://github.com/python/typing/issues/985
All in all, I don't think that we need a PEP for three reasons:
1. properties are already supported in all type checkers (with special casing),
if it does not cause any trouble, existing behavior can be left untouched. Mypy
has multiple problem with our special casing
2. Underlying mechanism - which are descriptors - is also supported
3. Change is relatively small, it does not add any new concepts
Feedback on this is welcome! Maybe I am missing something.
> Honestly I think it's too soon for a PR given that we don't seem to have
> agreement in the typing tracker discussion.
This PR is really small. It took me like 30 mins, but we have a reference now.
We can close it anytime with no damage done!
--
___
Python tracker
<https://bugs.python.org/issue46162>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Nikita Sobolev added the comment: Serhiy, no, we can infer that. There are two general cases: 1. `x = property(x_get, x_set)`, it is just ideal 2. `@property x` and `@x.setter`, it is also inferable with a bit of special casing for the mutable type part (we mutate the type of `x` when adding a setter) -- ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ 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
Nikita Sobolev added the comment: This seems like a good idea to me. I will send a PR for others to judge :) -- nosy: +sobolevn ___ 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
[issue46178] Remove `.travis.yml`?
New submission from Nikita Sobolev : Travis does not seem to be used anymore. There are not builds in Travis for cpython on `.org`: https://travis-ci.org/github/python/cpython/builds The last build on `.com` is 6 month old: https://app.travis-ci.com/github/python/cpython/builds If some information from this file will be needed in the future, we can always find its legacy version in git. I will send a PR! -- components: Build messages: 409182 nosy: sobolevn priority: normal severity: normal status: open title: Remove `.travis.yml`? type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46178] Remove `.travis.yml`?
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28478 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30257 ___ Python tracker <https://bugs.python.org/issue46178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46178] Remove `.travis.yml`?
Nikita Sobolev added the comment: Permanent link to the last version of this file: https://github.com/python/cpython/blob/078abb676cf759b1e960f78390b6e80f256f0255/.travis.yml -- ___ Python tracker <https://bugs.python.org/issue46178> ___ ___ 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
Nikita Sobolev added the comment: > I'd be happy to patch this myself if this sounds like a good idea. Oh, please, go ahead! :) Would be happy to review. -- ___ 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
Nikita Sobolev added the comment:
> So maybe those docs are incorrect? I can't find anything in PEP 484 about
> this.
Mypy even has an explicit test that NewType of NewType should work:
https://github.com/python/mypy/blob/f96446ce2f99a86210b21d39c7aec4b13a8bfc66/test-data/unit/check-newtype.test#L162-L165
I tend to agree with this behavior. This allows us to create complex type-safe
DSLs:
```python
from typing import NewType
UserId = NewType('UserId', int)
ProUserId = NewType('ProUserId', UserId)
x: ProUserId = ProUserId(UserId(1))
```
Mypy is happy with that!
I will open a new issue about incorrect docs.
--
___
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
Nikita Sobolev added the comment: Turns out modern docs already have this problem fixed: https://docs.python.org/3/library/typing.html#newtype -- ___ 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
[issue46184] Remove `netlify.toml`?
New submission from Nikita Sobolev : It was added one year ago in https://bugs.python.org/issue37860 But, it is not used. Right now it does not do anything. Others report that it has a lot of limitations (including financial and technical ones): https://github.com/python/cpython/pull/15288#issuecomment-579476340 Original author even proposed another solution: https://bugs.python.org/issue37860 (PR is stale) I propose to remove it. It can always be found in git. Permalink to the last version in `main`: https://github.com/python/cpython/blob/2e3e0d23adca8d83722d939d6abd1e467d7578f7/netlify.toml Related issue about `.travis.yml`: https://bugs.python.org/issue46178 -- components: Build messages: 409220 nosy: sobolevn priority: normal severity: normal status: open title: Remove `netlify.toml`? type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46184] Remove `netlify.toml`?
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28487 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30272 ___ Python tracker <https://bugs.python.org/issue46184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46120] Add note to `typing.Union` that it is recommended to use `|` instead
Nikita Sobolev added the comment: Thank you for your time, Łukasz! -- ___ Python tracker <https://bugs.python.org/issue46120> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46198] Duplicated test name `test_get_unstructured_invalid_ew` in `test__header_value_parser.py`
New submission from Nikita Sobolev : There are two tests with the same name in a same test class in `Lib/test/test_email/test__header_value_parser.py`: `test_get_unstructured_invalid_ew` 1. https://github.com/python/cpython/blob/8e11237c5d24e649b26cc928b52bc37f2fde9c7a/Lib/test/test_email/test__header_value_parser.py#L304 2. https://github.com/python/cpython/blob/8e11237c5d24e649b26cc928b52bc37f2fde9c7a/Lib/test/test_email/test__header_value_parser.py#L398 So, because of this bad naming - the first test is always shadowed by the second one and is silently skipped. With my patch: 1660 tests, without: 1659 tests. PR to rename the second test is on its way. -- components: Tests messages: 409338 nosy: sobolevn priority: normal severity: normal status: open title: Duplicated test name `test_get_unstructured_invalid_ew` in `test__header_value_parser.py` type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46198] Duplicated test name `test_get_unstructured_invalid_ew` in `test__header_value_parser.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28510 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30297 ___ Python tracker <https://bugs.python.org/issue46198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Nikita Sobolev added the comment:
I can verify that this happens on `3.10` and `main` branches:
```
from typing import Annotated, Optional, get_type_hints
class Foo:
def __init__(self, x: Annotated[Optional[str], "d"] = None): ...
class Foo2:
x: Annotated[Optional[str], "d"] = None
print(get_type_hints(Foo.__init__, include_extras=False)) # ok
# {'x': typing.Optional[str]}
print(get_type_hints(Foo2, include_extras=False)) # ok
# {'x': typing.Optional[str]}
print(get_type_hints(Foo.__init__, include_extras=True)) # not ok?
# {'x': typing.Optional[typing.Annotated[typing.Optional[str], 'd']]}
print(get_type_hints(Foo2, include_extras=True)) # ok
# {'x': typing.Annotated[typing.Optional[str], 'd']}
```
Notice that 3rd case does not look correct: `{'x':
typing.Optional[typing.Annotated[typing.Optional[str], 'd']]}`
In my opinion it should be `{'x': typing.Annotated[typing.Optional[str], 'd']}`
I will look into it! :)
--
nosy: +sobolevn
___
Python tracker
<https://bugs.python.org/issue46195>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Change by Nikita Sobolev : -- versions: +Python 3.10, Python 3.11 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue46195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Nikita Sobolev added the comment: And on 3.9 as well. -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue46195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Nikita Sobolev added the comment: As Guido said, the root cause of this problem is because `None` default automatically adds `Optional` to the resulting type. Source: https://github.com/python/cpython/blob/8d7644fa64213207b8dc6f555cb8a02bfabeced2/Lib/typing.py#L1854-L1856 So, what happens there: - correct `value` is passed to `_eval_type`, correct result `typing.Annotated[typing.Optional[str], 'd']` is returned at this point - then `if name in defaults and defaults[name] is None:` adds extra `Optional` annotation on top of `Annotated` > in the past a default of None automatically caused an Optional to be added, but we changed our minds Guido, are you talking about https://github.com/python/typing/issues/275 ? Now all type-checkers (AFAIK) support something similar to `--no-implicit-optional` mode. Having this in mind, I see different solutions to the current problem: 1. Remove `Optional` inference with `None` default. This is going to be a some-what breaking change. The only positive side of this is that we can really simplify our code (mainly because the other solution is to complicate our code even more). 2. Or we can change this place to explicitly check for `Annotated` type and its internal type. This should be the easiest to write and backport. But, it still has some complexity to it. I think that this is a better solution: we don't break existing behavior, change is local and pretty trivial. Also caused by this: - https://bugs.python.org/issue42921 - https://bugs.python.org/issue42288 -- ___ Python tracker <https://bugs.python.org/issue46195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46196] documentation for cmd library should include columnize() function
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 2.0 -> 3.0 pull_requests: +28516 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30303 ___ Python tracker <https://bugs.python.org/issue46196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46195] Annotated and Optional get_type_hints buggy interaction
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28517 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30304 ___ Python tracker <https://bugs.python.org/issue46195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46198] Duplicated test name `test_get_unstructured_invalid_ew` in `test__header_value_parser.py`
Nikita Sobolev added the comment: Eric, should I patch this as well in this issue? Or should I open a new one? Would be happy to fix it :) -- ___ Python tracker <https://bugs.python.org/issue46198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46198] Duplicate and unused code in tests
Nikita Sobolev added the comment: Thanks! I will also attach all `flake8`'s output if someone is going to need it: ``` » flake8 --select=F811 Lib/test Lib/test/test_descr.py:1165:13: F811 redefinition of unused 'C' from line 1158 Lib/test/test_descr.py:1172:13: F811 redefinition of unused 'C' from line 1165 Lib/test/test_descr.py:1179:13: F811 redefinition of unused 'C' from line 1172 Lib/test/test_descr.py:1186:13: F811 redefinition of unused 'C' from line 1179 Lib/test/test_descr.py:1192:9: F811 redefinition of unused 'C' from line 1186 Lib/test/test_descr.py:1198:9: F811 redefinition of unused 'C' from line 1192 Lib/test/test_descr.py:1488:13: F811 redefinition of unused 'C' from line 1480 Lib/test/test_descr.py:1498:13: F811 redefinition of unused 'C' from line 1488 Lib/test/test_descr.py:1506:13: F811 redefinition of unused 'C' from line 1498 Lib/test/test_descr.py:1514:13: F811 redefinition of unused 'C' from line 1506 Lib/test/test_descr.py:4076:13: F811 redefinition of unused 'X' from line 4073 Lib/test/test_descr.py:4079:13: F811 redefinition of unused 'X' from line 4076 Lib/test/test_descr.py:4084:13: F811 redefinition of unused 'X' from line 4079 Lib/test/test_descr.py:4087:13: F811 redefinition of unused 'X' from line 4084 Lib/test/test_descr.py:4090:9: F811 redefinition of unused 'X' from line 4087 Lib/test/test_buffer.py:759:5: F811 redefinition of unused 'genslices' from line 694 Lib/test/test_buffer.py:760:5: F811 redefinition of unused 'genslices_ndim' from line 698 Lib/test/test_buffer.py:761:5: F811 redefinition of unused 'permutations' from line 20 Lib/test/test_syntax.py:1555:5: F811 redefinition of unused 'test_break_outside_loop' from line 1525 Lib/test/test_typing.py:108:13: F811 redefinition of unused 'A' from line 105 Lib/test/test_typing.py:148:13: F811 redefinition of unused 'A' from line 145 Lib/test/test_typing.py:332:13: F811 redefinition of unused 'C' from line 329 Lib/test/test_typing.py:335:13: F811 redefinition of unused 'C' from line 332 Lib/test/test_typing.py:880:13: F811 redefinition of unused 'P' from line 877 Lib/test/test_typing.py:883:13: F811 redefinition of unused 'P' from line 880 Lib/test/test_typing.py:1385:13: F811 redefinition of unused 'P' from line 1383 Lib/test/test_typing.py:1387:13: F811 redefinition of unused 'P' from line 1385 Lib/test/test_typing.py:1389:13: F811 redefinition of unused 'P' from line 1387 Lib/test/test_typing.py:1665:13: F811 redefinition of unused 'MyGeneric' from line 1663 Lib/test/test_typing.py:2295:13: F811 redefinition of unused 'Subclass' from line 2292 Lib/test/test_typing.py:2478:13: F811 redefinition of unused 'C' from line 2475 Lib/test/test_typing.py:2522:13: F811 redefinition of unused 'C' from line 2519 Lib/test/test_typing.py:4532:5: F811 redefinition of unused 'test_hash_eq' from line 4475 Lib/test/test_typing.py:4652:13: F811 redefinition of unused 'C' from line 4648 Lib/test/test_typing.py:4844:13: F811 redefinition of unused 'C' from line 4841 Lib/test/datetimetester.py:1867:9: F811 redefinition of unused 'io' from line 5 Lib/test/datetimetester.py:3991:9: F811 redefinition of unused 'io' from line 5 Lib/test/test_genericclass.py:101:13: F811 redefinition of unused 'D' from line 95 Lib/test/test_genericclass.py:114:13: F811 redefinition of unused 'D' from line 108 Lib/test/test_subclassinit.py:235:13: F811 redefinition of unused 'MyClass' from line 221 Lib/test/test_subclassinit.py:246:9: F811 redefinition of unused 'MyClass' from line 235 Lib/test/test_subclassinit.py:268:9: F811 redefinition of unused 'MyClass' from line 259 Lib/test/test_tabnanny.py:7:1: F811 redefinition of unused 'mock' from line 6 Lib/test/test_compile.py:1178:5: F811 redefinition of unused 'test_func_args' from line 1171 Lib/test/test_dataclasses.py:517:13: F811 redefinition of unused 'A' from line 512 Lib/test/test_dataclasses.py:527:13: F811 redefinition of unused 'A' from line 517 Lib/test/test_dataclasses.py:681:21: F811 redefinition of unused 'Point' from line 672 Lib/test/test_dataclasses.py:692:21: F811 redefinition of unused 'Point' from line 681 Lib/test/test_dataclasses.py:702:17: F811 redefinition of unused 'C' from line 697 Lib/test/test_dataclasses.py:1840:9: F811 redefinition of unused 'C' from line 1834 Lib/test/test_dataclasses.py:2387:13: F811 redefinition of unused 'C' from line 2378 Lib/test/test_dataclasses.py:2396:13: F811 redefinition of unused 'C' from line 238
[issue46198] Duplicate and unused code in tests
Nikita Sobolev added the comment: > I think most of these are false positives Yes, they are! Please, check out my PR: https://github.com/python/cpython/pull/30297 сб, 1 янв. 2022 г. в 21:52, Éric Araujo : > > Éric Araujo added the comment: > > I think most of these are false positives (it’s fine if 10 different tests > define a function `f`), so should not be changed just to appease a lint > tool. Others are genuine! > > -- > > ___ > Python tracker > <https://bugs.python.org/issue46198> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46184] Remove `netlify.toml`?
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46178] Remove `.travis.yml`?
Nikita Sobolev added the comment: Thanks everyone! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46229] CODE_OF_CONDUCT shadowing org default
New submission from Nikita Sobolev : Problem: we have two CODE_OF_CONDUCT files. 1. In CPython: https://github.com/python/cpython/blob/main/CODE_OF_CONDUCT.md (last updated 3 years ago) 2. In Python org, default for all repos: https://github.com/python/.github/blob/master/CODE_OF_CONDUCT.md But, since CODE_OF_CONDUCT is an important document, I want to raise a discussion first. Should it be deleted from CPython repo? Pros: GitHub offers org-default and CODE_OF_CONDUCT will still be rendered in several places: - https://user-images.githubusercontent.com/4660275/147888475-f1bc5e79-078b-4ec7-9484-53b90373c3c9.png - https://user-images.githubusercontent.com/4660275/147888477-35c98df8-2730-4d9b-a568-76b6b46da015.png It will be also easier to edit a single-source-of-truth. For example, this commit was not back-ported to CPython: https://github.com/python/.github/commit/237d2151f18380c8146557febfe5858fe3f23232 Also, other repos like mypy / typeshed / typing use org-default CoC. Cons: some people might still miss that CPython has a CoC. This is a follow-up to: https://github.com/python/cpython/pull/30294 If others agree, I can send a PR to remove CPython's local copy of CoC. -- files: Снимок экрана 2022-01-02 в 23.19.15.png messages: 409519 nosy: Mariatta, sobolevn priority: normal severity: normal status: open title: CODE_OF_CONDUCT shadowing org default type: behavior versions: Python 3.11 Added file: https://bugs.python.org/file50537/Снимок экрана 2022-01-02 в 23.19.15.png ___ Python tracker <https://bugs.python.org/issue46229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46229] CODE_OF_CONDUCT shadowing org default
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28554 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30342 ___ Python tracker <https://bugs.python.org/issue46229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46238] Improve constants usage / definition in asyncio.windows_events
New submission from Nikita Sobolev : There are several problems in https://github.com/python/cpython/blob/549e62827262264cda30455e10e315602129da72/Lib/asyncio/windows_events.py#L31-L32 1. For some reason this module uses both `NULL` and `_winapi.NULL`, `INFINITE` and `_winapi.INFINITE`. There's no system to it. Besides, they are have equal values. I think it better to use aliases to `_winapi` constants than redefine them 2. Here https://github.com/python/cpython/blob/549e62827262264cda30455e10e315602129da72/Lib/asyncio/windows_events.py#L408 `INFINITE` is not used, but should. It would increase readability. Compare: - `def __init__(self, concurrency=0x):` < not clear - `def __init__(self, concurrency=INFINITE):` < clear The PR is on its way. -- components: asyncio messages: 409570 nosy: asvetlov, sobolevn, yselivanov priority: normal severity: normal status: open title: Improve constants usage / definition in asyncio.windows_events type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46238] Improve constants usage / definition in asyncio.windows_events
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28565 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30352 ___ Python tracker <https://bugs.python.org/issue46238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46239] Incosistent error message in asyncio: windows_events / windows_utils
New submission from Nikita Sobolev :
When trying to import both `windows_events` and `windows_utils` on non-Windows,
they both fail.
But, they fail differently. `windows_utils` produces a good error message, whil
`windows_events` produces a strange one.
Good:
```
Python 3.11.0a3+ (heads/main:8d7644fa64, Dec 30 2021, 13:00:40) [Clang 11.0.0
(clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio.windows_utils
Traceback (most recent call last):
File "", line 1, in
File "/Users/sobolev/Desktop/cpython/Lib/asyncio/windows_utils.py", line 6,
in
raise ImportError('win32 only')
^^^
ImportError: win32 only
```
Not so good:
```
>>> import asyncio.windows_events
Traceback (most recent call last):
File "", line 1, in
File "/Users/sobolev/Desktop/cpython/Lib/asyncio/windows_events.py", line 3,
in
import _overlapped
^^
ModuleNotFoundError: No module named '_overlapped'
```
I propose to use the same error message `windows_utils` does.
--
components: asyncio
messages: 409571
nosy: asvetlov, sobolevn, yselivanov
priority: normal
severity: normal
status: open
title: Incosistent error message in asyncio: windows_events / windows_utils
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46239>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46239] Incosistent error message in asyncio: windows_events / windows_utils
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28566 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30353 ___ Python tracker <https://bugs.python.org/issue46239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46242] Improve error message when creating an enum with `__call__`
New submission from Nikita Sobolev :
Right now when creating a new `Enum`, we check not to extend `Enum` with
existing `_member_names_`:
```python
Python 3.11.0a3+ (heads/main:8d7644fa64, Dec 30 2021, 13:00:40) [Clang 11.0.0
(clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import enum
>>> class A(enum.Enum):
... a = 1
...
>>> class B(A): pass
...
Traceback (most recent call last):
File "", line 1, in
File "/Users/sobolev/Desktop/cpython/Lib/enum.py", line 398, in __prepare__
metacls._check_for_existing_members(cls, bases)
^^^
File "/Users/sobolev/Desktop/cpython/Lib/enum.py", line 850, in
_check_for_existing_members
raise TypeError(
TypeError: B: cannot extend enumeration 'A'
```
But when we try to use `A()` call to do the same, where what happens:
```
Python 3.11.0a3+ (heads/main:8d7644fa64, Dec 30 2021, 13:00:40) [Clang 11.0.0
(clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import enum
>>> class A(enum.Enum):
... a = 1
...
>>> B = A('B', 'b')
Traceback (most recent call last):
File "", line 1, in
File "/Users/sobolev/Desktop/cpython/Lib/enum.py", line 606, in __call__
return cls._create_(
^
File "/Users/sobolev/Desktop/cpython/Lib/enum.py", line 770, in _create_
_, first_enum = cls._get_mixins_(class_name, bases)
^^^
File "/Users/sobolev/Desktop/cpython/Lib/enum.py", line 899, in _get_mixins_
raise TypeError('Cannot extend enumerations')
^
TypeError: Cannot extend enumerations
```
I propose to use the first error message in this case as well. Moreover, this
behavior is not covered with tests:
```
» ag 'Cannot extend enumerations'
Lib/enum.py
899:raise TypeError('Cannot extend enumerations')
```
I will add tests for this edge case.
--
components: Library (Lib)
messages: 409583
nosy: ethan.furman, pablogsal, sobolevn
priority: normal
severity: normal
status: open
title: Improve error message when creating an enum with `__call__`
type: behavior
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue46242>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46242] Improve error message when creating an enum with `__call__`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28571 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30357 ___ Python tracker <https://bugs.python.org/issue46242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46262] Error path in `_missing_()` is not covered for `enum.Flag` and `enum.IntFlag`
New submission from Nikita Sobolev : I've noticed that `enum.Flag._missing_` has some uncovered paths. For example, this error is never checked: https://github.com/python/cpython/blob/31e43cbe5f01cdd5b5ab330ec3040920e8b61a91/Lib/enum.py#L1222-L1225 The same method for `Enum` has good coverage: https://github.com/python/cpython/blob/31e43cbe5f01cdd5b5ab330ec3040920e8b61a91/Lib/test/test_enum.py#L2278-L2325 I've added two simple test cases for `Flag` and `IntFlag` that check this. -- components: Tests messages: 409717 nosy: sobolevn priority: normal severity: normal status: open title: Error path in `_missing_()` is not covered for `enum.Flag` and `enum.IntFlag` type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46262] Error path in `_missing_()` is not covered for `enum.Flag` and `enum.IntFlag`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28614 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30408 ___ Python tracker <https://bugs.python.org/issue46262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
New submission from Nikita Sobolev : For some reasons useful day constants (`MONDAY` ... `SUNDAY`) from `calendar` are not properly recognised. Several problems: 0. Not all code inside uses these constants 1. They are not tested. Only `.MONDAY` and `.SUNDAY` are tested to be present in https://github.com/python/cpython/blob/main/Lib/test/test_calendar.py#L508-L511 2. They are not in `__all__` 3. They are partially documented. There are some notes about them in https://docs.python.org/3/library/calendar.html#calendar.setfirstweekday > Sets the weekday (0 is Monday, 6 is Sunday) to start each week. The values > :const:`MONDAY`, :const:`TUESDAY`, :const:`WEDNESDAY`, :const:`THURSDAY`, > :const:`FRIDAY`, :const:`SATURDAY`, and :const:`SUNDAY` are provided for > convenience. For example, to set the first weekday to Sunday: >import calendar >calendar.setfirstweekday(calendar.SUNDAY) But, they are not clickable, because, for example, ":const:`MONDAY`" does not exist in docs index. So, my plan is: 0. Improve constant usage in the source code to make it more readable 1. Test that constants are there 2. Add them to `__all__` as a part of public API 3. Improve their docs -- components: Library (Lib) messages: 409742 nosy: sobolevn priority: normal severity: normal status: open title: Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py` type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28618 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30412 ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46268] Buildbot failure for buildbot/AMD64 FreeBSD Non-Debug / Shared 3.x
New submission from Nikita Sobolev : Log: ``` --- sharedmods --- LD_LIBRARY_PATH=/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build CC='cc -pthread' LDSHARED='cc -pthread -shared' OPT='-g -O0 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py build Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/./setup.py", line 49, in from distutils.command.build_ext import build_ext ^ File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/distutils/command/build_ext.py", line 13, in from distutils.sysconfig import customize_compiler, get_python_version ^^ File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/distutils/sysconfig.py", line 53, in _config_vars = get_config_vars() ^ File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/sysconfig.py", line 621, in get_config_vars _init_posix(_CONFIG_VARS) ^ File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/sysconfig.py", line 482, in _init_posix _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0) ^ ModuleNotFoundError: No module named '_sysconfigdata_d_freebsd14_x86_64-unknown-freebsd14' *** [sharedmods] Error code 1 make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd-564d/build ``` Link: https://buildbot.python.org/all/#/builders/483/builds/1409 -- components: Build messages: 409760 nosy: sobolevn priority: normal severity: normal status: open title: Buildbot failure for buildbot/AMD64 FreeBSD Non-Debug / Shared 3.x type: compile error versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46268] Buildbot failure for buildbot/AMD64 FreeBSD Non-Debug / Shared 3.x
Nikita Sobolev added the comment: It also generates several warnings: ``` Python/pytime.c:297:10: warning: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion] Python/pytime.c:352:14: warning: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion] Python/pytime.c:507:10: warning: implicit conversion from 'long' to 'double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion] ./Modules/expat/xmlparse.c:3095:9: warning: code will never be executed [-Wunreachable-code] ./Modules/expat/xmlparse.c:3787:9: warning: code will never be executed [-Wunreachable-code] ./Modules/_threadmodule.c:1648:26: warning: implicit conversion from '_PyTime_t' (aka 'long') to 'double' changes value from 9223372036854775 to 9223372036854776 [-Wimplicit-int-float-conversion] 1 warning generated. /usr/include/netgraph/bluetooth/include/ng_btsocket.h:244:2: warning: "Make sure new member of socket address initialized" [-W#warnings] #warning "Make sure new member of socket address initialized" 1 warning generated. /usr/include/netgraph/bluetooth/include/ng_btsocket.h:244:2: warning: "Make sure new member of socket address initialized" [-W#warnings] #warning "Make sure new member of socket address initialized" 1 warning generated. ``` -- ___ Python tracker <https://bugs.python.org/issue46268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46269] '__new__' is never shown in `dir(SomeEnum)`
New submission from Nikita Sobolev : Right now `__new__` is marked to be special-cased in `Enum.__dir__`. It is generally ignored: But, (I think that was the original idea), when `__new__` is overridden, it should be added to the output. But, this line is problematic: https://github.com/python/cpython/blame/46e4c257e7c26c813620232135781e6c53fe8d4d/Lib/enum.py#L656 Why? Because `self.__new__` is always `EnumMeta.__new__`. Original `__new__` is renamed to `_new_member_`. This behavior is also not tested. So, my proposal is: let's always remove this method from `__dir__`. Why? - If we modify the check above to compare `_new_member_`, we will show `__new__` as the output. It is kinda misleading - `__new__` is not supposed to be overloaded in `EnumMeta`, it is very special - `__new__` is a very basic thing. It would be kinda strange not to see it for some cases, but to see it for others. For example, all (?) other data types always show `__new__`, even if it is not explicitly defined: ``` >>> class A: ...def __new__(*args, **kwargs): ... ... >>> assert '__new__' in dir(A) >>> class B: ... ... >>> assert '__new__' in dir(B) ``` I guess being consistent here (we don't show `__new__` at all times) is better. I will send a PR that removes these two lines in a moment! Any other ideas are much appreciated! Related: - https://bugs.python.org/issue45535 - https://github.com/python/cpython/pull/29316 -- components: Library (Lib) messages: 409771 nosy: AlexWaygood, ethan.furman, sobolevn priority: normal severity: normal status: open title: '__new__' is never shown in `dir(SomeEnum)` type: behavior ___ Python tracker <https://bugs.python.org/issue46269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46269] '__new__' is never shown in `dir(SomeEnum)`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28625 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30421 ___ Python tracker <https://bugs.python.org/issue46269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46266] Improve day constants (`MONDAY` ... `SUNDAY`) in `calendar.py`
Nikita Sobolev added the comment: > I don't think these were intended to be public. Thanks for the feedback! The problem is they are documented here: https://docs.python.org/3/library/calendar.html#calendar.setfirstweekday Should we change the docs there to hide them as implementation detail? Because the current state looks inconsistent to me. -- ___ Python tracker <https://bugs.python.org/issue46266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46291] [doc] First argument to raise can also be BaseException
Nikita Sobolev added the comment: I think that this is intentional: tutorial gives some very basic ideas about what can be raised. Giving the whole context (you can `raise` two kinds of errors: `Exception` and `BaseException`, but they are different, should be used in different cases, and they are caught differently). Probably most users don't need to subclass `BaseException` at all. And if they need to: there are docs for that https://docs.python.org/3/library/exceptions.html#BaseException In my opinion - nothing should be changed there :) -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46296] Unreachable condition: `if enum_class._member_type_ is object`
New submission from Nikita Sobolev : This condition can never be `True`: https://github.com/python/cpython/blob/b127e70a8a682fe869c22ce04c379bd85a00db67/Lib/enum.py#L222-L223 Why? Because: 1. It is executed only when `if not enum_class._use_args_:`: https://github.com/python/cpython/blob/b127e70a8a682fe869c22ce04c379bd85a00db67/Lib/enum.py#L215 2. But, `enum_class._use_args_` will always be `False` for cases when `enum_class._member_type_` is `object` 3. It is defined here: https://github.com/python/cpython/blob/b127e70a8a682fe869c22ce04c379bd85a00db67/Lib/enum.py#L937 So, I guess that removing this condition can simplify the `enum.py`. Coverage shows that this part is not tested. I will send a PR shortly. -- components: Library (Lib) messages: 409989 nosy: sobolevn priority: normal severity: normal status: open title: Unreachable condition: `if enum_class._member_type_ is object` versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46296] Unreachable condition: `if enum_class._member_type_ is object`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28661 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30458 ___ Python tracker <https://bugs.python.org/issue46296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46296] Unreachable condition: `if enum_class._member_type_ is object`
Nikita Sobolev added the comment: Yes, this is just a missing test. Not a wrong condition! -- components: +Tests -Library (Lib) ___ Python tracker <https://bugs.python.org/issue46296> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46299] Improve several exception handling practices in `test_descr.py`
New submission from Nikita Sobolev : There are several problems in `test_descr.py` that I've found: 1. In `test_dir` there's a test case that ensure that `TypeError` is raised in some case: https://github.com/python/cpython/blame/c9dc1f491e8edb0bc433cde73190a3015d226891/Lib/test/test_descr.py#L2548-L2551 But it never does anything if this error is not raised. So, this test can contain a possible problem inside. It will just skip a scenario where `TypeError` is not thrown. 2. The same with `test_file_failt` here: https://github.com/python/cpython/blame/c9dc1f491e8edb0bc433cde73190a3015d226891/Lib/test/test_descr.py#L4451-L4456 If `RuntimeError` is not thrown - nothing happens 3. `assert 0, ...` is problematic: https://github.com/python/cpython/blame/c9dc1f491e8edb0bc433cde73190a3015d226891/Lib/test/test_descr.py#L4451-L4456 It can be dropped in optimized mode and it's error message is not ideal I will send a PR with all these problems fixed. -- components: Tests messages: 410050 nosy: sobolevn priority: normal severity: normal status: open title: Improve several exception handling practices in `test_descr.py` type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46299] Improve several exception handling practices in `test_descr.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28674 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30471 ___ Python tracker <https://bugs.python.org/issue46299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46301] One branch is not covered in `Enum._convert_`
New submission from Nikita Sobolev : This branch is never covered: https://github.com/python/cpython/blob/c9dc1f491e8edb0bc433cde73190a3015d226891/Lib/enum.py#L831 I will send a PR in a moment :) -- components: Tests messages: 410053 nosy: sobolevn priority: normal severity: normal status: open title: One branch is not covered in `Enum._convert_` type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46301> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46301] One branch is not covered in `Enum._convert_`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28675 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30472 ___ Python tracker <https://bugs.python.org/issue46301> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46305] SyntaxError when using dict key in fstring
Nikita Sobolev added the comment:
Can you please try this:
```
dict1 = {
"key1": "test"
}
print(dict1["key1"])
print(f"key1 is {dict1['key1']}!")
```
The problem with your code is that `dict1["key1"]` used the same quotes as
`f""`.
--
nosy: +sobolevn
___
Python tracker
<https://bugs.python.org/issue46305>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46223] asyncio cause infinite loop during debug
Nikita Sobolev added the comment: Just to clarify. What do you mean by "When running code in debug mode"? Do you use some debugger like `pdb` or pycharm? -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46306] Suspicios operation in `doctest.py`: `None - 1`
New submission from Nikita Sobolev :
This line `lineno = getattr(obj, 'co_firstlineno', None)-1` does not look good.
Link:
https://github.com/python/cpython/blame/45d44b950f1dab0ef90d0a8f4fa75ffaae71500b/Lib/doctest.py#L1116
Why?
1. `CodeType` is guaranteed to have `co_firstlineno`. Docs:
https://github.com/python/cpython/blob/45d44b950f1dab0ef90d0a8f4fa75ffaae71500b/Lib/inspect.py#L487
2. Even if it does not have it for some reason, this `getattr` does not help.
It raises unhandled `TypeError`. We can simulate it by replacing `lineno =
getattr(obj, 'co_firstlineno', None)-1` with `lineno = None-1`
Here's what happens in this case:
```
» ./python.exe -m test -v test_doctest
== CPython 3.11.0a3+ (heads/issue-26767:45d44b950f, Jan 8 2022, 12:23:45)
[Clang 11.0.0 (clang-1100.0.33.16)]
== Darwin-18.7.0-x86_64-i386-64bit little-endian
== cwd: /Users/sobolev/Desktop/cpython/build/test_python_78065æ
== CPU count: 4
== encodings: locale=UTF-8, FS=utf-8
0:00:00 load avg: 3.51 Run tests sequentially
0:00:00 load avg: 3.51 [1/1] test_doctest
Failed to call load_tests:
Traceback (most recent call last):
File "/Users/sobolev/Desktop/cpython/Lib/unittest/loader.py", line 108, in
loadTestsFromModule
return load_tests(self, tests, pattern)
File "/Users/sobolev/Desktop/cpython/Lib/test/test_doctest.py", line 3134, in
load_tests
tests.addTest(doctest.DocTestSuite(doctest))
^
File "/Users/sobolev/Desktop/cpython/Lib/doctest.py", line 2391, in
DocTestSuite
tests = test_finder.find(module, globs=globs, extraglobs=extraglobs)
File "/Users/sobolev/Desktop/cpython/Lib/doctest.py", line 940, in find
self._find(tests, obj, name, module, source_lines, globs, {})
^
File "/Users/sobolev/Desktop/cpython/Lib/doctest.py", line 1013, in _find
self._find(tests, val, valname, module, source_lines,
^
File "/Users/sobolev/Desktop/cpython/Lib/doctest.py", line 1001, in _find
test = self._get_test(obj, name, module, globs, source_lines)
^^
File "/Users/sobolev/Desktop/cpython/Lib/doctest.py", line 1069, in _get_test
lineno = self._find_lineno(obj, source_lines)
File "/Users/sobolev/Desktop/cpython/Lib/doctest.py", line 1117, in
_find_lineno
None - 1
~^~~
TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'
test test_doctest crashed -- Traceback (most recent call last):
File "/Users/sobolev/Desktop/cpython/Lib/test/libregrtest/runtest.py", line
352, in _runtest_inner
refleak = _runtest_inner2(ns, test_name)
^^
File "/Users/sobolev/Desktop/cpython/Lib/test/libregrtest/runtest.py", line
309, in _runtest_inner2
test_runner()
^
File "/Users/sobolev/Desktop/cpython/Lib/test/libregrtest/runtest.py", line
272, in _test_module
raise Exception("errors while loading tests")
^
Exception: errors while loading tests
test_doctest failed (uncaught exception)
== Tests result: FAILURE ==
1 test failed:
test_doctest
Total duration: 1.0 sec
Tests result: FAILURE
```
So, we have two options:
1. Think of a case when `CodeType` does not have `co_firstlineno` and handle it
properly, like using `0` or `None` as `lineno`
2. Simplify this line to remove potential `TypeError`
I think that this line should be rewritten as `lineno = obj.co_firstlineno - 1`
I will send a PR for others to judge.
--
components: Library (Lib)
messages: 410092
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Suspicios operation in `doctest.py`: `None - 1`
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46306>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46306] Suspicios operation in `doctest.py`: `None - 1`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28685 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30481 ___ Python tracker <https://bugs.python.org/issue46306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46310] Simplify `for` loop in `.close()` method in `asyncio/windows_events`
New submission from Nikita Sobolev :
This line
https://github.com/python/cpython/blob/3d11c1b8b49800c5c4c295953cc3abf577f6065a/Lib/asyncio/windows_events.py#L842
uses `.items()`, but the key seems unsused.
It would be better to use `.values()` there.
1. It is slightly faster, very generic benchmark:
```
import timeit
cache = {i: (i, i + 1, None, f'a{i}') for i in range(1000)}
timeit.timeit('list(cache.items())', number=1000, globals=locals())
# 0.18165644304826856
timeit.timeit('list(cache.values())', number=1000, globals=locals())
# 0.04786261299159378
```
2. It is more readable, because unused variables are not created
And since it does not break anything, I think it is safe to refactor.
--
assignee: sobolevn
components: Library (Lib)
messages: 410136
nosy: asvetlov, eric.araujo, sobolevn
priority: normal
severity: normal
status: open
title: Simplify `for` loop in `.close()` method in `asyncio/windows_events`
type: behavior
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46310>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46310] Simplify `for` loop in `.close()` method in `asyncio/windows_events`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28701 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30334 ___ Python tracker <https://bugs.python.org/issue46310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28249] doctest.DocTestFinder reports incorrect line numbers with exclude_empty=False
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 2.0 -> 3.0 pull_requests: +28704 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30498 ___ Python tracker <https://bugs.python.org/issue28249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43698] Use syntactically correct examples on abc package page
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 2.0 -> 3.0 pull_requests: +28708 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30502 ___ Python tracker <https://bugs.python.org/issue43698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43698] Use syntactically correct examples on abc package page
Nikita Sobolev added the comment: Thank you, I fully agree that this can be improved. Please, take a look at https://github.com/python/cpython/pull/30502 I will apprecaite your review! -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue43698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46301] Enum tests: One branch is not covered in `Enum._convert_`
Change by Nikita Sobolev : -- pull_requests: +28714 pull_request: https://github.com/python/cpython/pull/30510 ___ Python tracker <https://bugs.python.org/issue46301> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46327] `test_enum` contains tests for older versions of python
New submission from Nikita Sobolev : Here's the problem: https://github.com/python/cpython/blob/main/Lib/test/test_enum.py#L4515-L4531 Why it is a problem? 1. First test is marked as `@unittest.skipUnless(python_version == (3, 8)`. Which means it is only executed on `3.8`. I think it should be removed from more recent branches 2. Second test is marked as `@unittest.skipUnless(python_version >= (3, 9)`. Which means that it will be executed on three currently supported branches. I think we can remove this decorator I will send a PR today. -- components: Tests messages: 410194 nosy: ethan.furman, sobolevn priority: normal severity: normal status: open title: `test_enum` contains tests for older versions of python type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46327] `test_enum` contains tests for older versions of python
Nikita Sobolev added the comment:
On the other hand second test
```python
@unittest.skipUnless(python_version >= (3, 9),
'_convert was removed in 3.9')
def test_convert_raise(self):
with self.assertRaises(AttributeError):
enum.IntEnum._convert(
'UnittestConvert',
MODULE,
filter=lambda x: x.startswith('CONVERT_TEST_'))
```
can also be removed if needed.
--
___
Python tracker
<https://bugs.python.org/issue46327>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46327] `test_enum` contains tests for older versions of python
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28715 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30512 ___ Python tracker <https://bugs.python.org/issue46327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46327] `test_enum` contains tests for older versions of python
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43681] doctest forgets previous imports
Nikita Sobolev added the comment: Ethan, I've tried to reproduce this, but it seems that example you attached is not valid. `Flag` is never imported at all. The same with `auto`. Should it be: ``` >>> from enum import auto, Flag, STRICT ``` the first time? As you said, it only happens in rare envs. For me the sample above works completely fine. I also can't find any historical logs from the CI failures :( Related: - https://github.com/python/cpython/pull/25118 - https://bugs.python.org/issue40066 -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue43681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45331] Can create enum of ranges, cannot create range enum. Range should be subclassable... or EnumMeta.__new__ should be smarter.
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 2.0 -> 3.0 pull_requests: +28722 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30521 ___ Python tracker <https://bugs.python.org/issue45331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46162] Make `builtins.property` generic
Nikita Sobolev added the comment: Looks like no one showed much interest in it :( So, yeah, closing it is probably the best idea. Thanks everyone! -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default
New submission from Nikita Sobolev :
Right now this corner case is not tested:
```python
class Some:
x: int = None
import typing
assert typing.get_type_hints(Some) == {'x': int}
```
Notice that we don't add implicit `Optional` type to `x`. This is different for
function arguments that will have `Optional` added.
I think it is a good idea to add a test for this. Espeically given that we can
change function's behavior.
Context:
- https://bugs.python.org/issue46195
- https://github.com/python/cpython/pull/30304
--
components: Library (Lib)
messages: 410307
nosy: sobolevn
priority: normal
severity: normal
status: open
title: Add an explicit test for `get_type_hints` for a class field with `None`
default
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46345>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default
Nikita Sobolev added the comment: I will send a PR today :) -- ___ Python tracker <https://bugs.python.org/issue46345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28736 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30535 ___ Python tracker <https://bugs.python.org/issue46345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46348] Morernize `test_typing`
New submission from Nikita Sobolev : There are several very old details in `test_typing`. Some examples: 1. `@skipUnless(sys.version_info >= (3, 3), 'ChainMap was added in 3.3')` https://github.com/python/cpython/blame/dce642f24418c58e67fa31a686575c980c31dd37/Lib/test/test_typing.py#L3583 Probably we don't care about `3.3` anymore, so this decorator cam be removed 2. Lib/test/mod_generics_cache.py has a specific path for 3.6, which has reached its EOL, so it can also be simplified 3. `ASYNCIO_TESTS` can be written as a regular code now (this is the one I am not 100% sure about, but let's see what the CI will say) PR is on its way! -- components: Library (Lib) messages: 410333 nosy: sobolevn priority: normal severity: normal status: open title: Morernize `test_typing` versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46348] Morernize `test_typing`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28747 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30547 ___ Python tracker <https://bugs.python.org/issue46348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46348] Modernize `test_typing`
Nikita Sobolev added the comment: Alex, thanks a lot for fixing so many of my titles! Highly appreciated! -- components: +Tests -Library (Lib) ___ Python tracker <https://bugs.python.org/issue46348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46358] Modernize `test_asyncio/test_base_events.py`
New submission from Nikita Sobolev : Right now there's a special case for python3.4 in `Lib/test/test_asyncio/test_base_events.py` file. Links: - https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_asyncio/test_base_events.py#L24 - https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_asyncio/test_base_events.py#L599 Python3.4 is long gone, I propose to remove this special case. PR is on its way :) -- components: Tests messages: 410430 nosy: sobolevn priority: normal severity: normal status: open title: Modernize `test_asyncio/test_base_events.py` type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46359] Continue to modernize `test_typing.py`
New submission from Nikita Sobolev : This is a follow up to: - https://bugs.python.org/issue46348 - https://github.com/python/cpython/pull/30547 There are several other cases I've missed: 1. There's a test that is only executed under `<3.6`. I think that it should be removed: https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_typing.py#L4093-L4099 2. Line `if sys.version_info[:2] > (3, 2):` https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_typing.py#L1943 3. Line `if sys.version_info >= (3, 3):` https://github.com/python/cpython/blob/0bbf30e2b910bc9c5899134ae9d73a8df968da35/Lib/test/test_typing.py#L2069 I hope that this is it! PR is on it way :) -- messages: 410431 nosy: sobolevn priority: normal severity: normal status: open title: Continue to modernize `test_typing.py` ___ Python tracker <https://bugs.python.org/issue46359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46359] Continue to modernize `test_typing.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28763 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30563 ___ Python tracker <https://bugs.python.org/issue46359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46358] Modernize `test_asyncio/test_base_events.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28762 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30562 ___ Python tracker <https://bugs.python.org/issue46358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46359] Continue to modernize `test_typing.py`
Change by Nikita Sobolev : -- components: +Tests type: -> behavior versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40838] inspect.getsourcefile documentation doesn't mention it can return None
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 3.0 -> 4.0 pull_requests: +28775 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30575 ___ Python tracker <https://bugs.python.org/issue40838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46359] Continue to modernize `test_typing.py`
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46369] get_type_hints does not evaluate ForwardRefs inside NewType
Nikita Sobolev added the comment: I think we should go with `1)` and `A`. Adding a special case for getting hints from `NewType` directly does seem inconsistent with other type-constructs. Do you want to fix this? :) Or I can work on it today if you wish! -- ___ Python tracker <https://bugs.python.org/issue46369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46369] get_type_hints does not evaluate ForwardRefs inside NewType
Nikita Sobolev added the comment: Oh, I mean `1)` and `B` -- ___ Python tracker <https://bugs.python.org/issue46369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46269] '__new__' is never shown in `dir(SomeEnum)`
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46345] Add an explicit test for `get_type_hints` for a class field with `None` default
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46380] `test_functools.TestLRU` must not use `functools` module directly
New submission from Nikita Sobolev : Right now there are two tests in Lib/test/test_functools.py that use `functools.lru_cache` directly: 1. https://github.com/python/cpython/blame/73140de97cbeb01bb6c9af1da89ecb9355921e91/Lib/test/test_functools.py#L1417 2. https://github.com/python/cpython/blame/73140de97cbeb01bb6c9af1da89ecb9355921e91/Lib/test/test_functools.py#L1429 But, I don't think it is correct. Why? ```python class TestLRUPy(TestLRU, unittest.TestCase): module = py_functools class TestLRUC(TestLRU, unittest.TestCase): module = c_functools ``` Source: https://github.com/python/cpython/blame/73140de97cbeb01bb6c9af1da89ecb9355921e91/Lib/test/test_functools.py#L1798-L1823 So, what can we do? 1. Use `self.module.lru_cache` instead (I think it is the right way) 2. Move them to `TestLRUPy`, but I don't think they should be python-specific -- components: Tests messages: 410579 nosy: sobolevn priority: normal severity: normal status: open title: `test_functools.TestLRU` must not use `functools` module directly type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
