[issue46480] Implement typing.assert_type
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 5.0 -> 6.0 pull_requests: +30158 pull_request: https://github.com/python/cpython/pull/32069 ___ Python tracker <https://bugs.python.org/issue46480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46998] Allow subclassing Any at runtime
Change by Shantanu : -- keywords: +patch pull_requests: +29941 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31841 ___ Python tracker <https://bugs.python.org/issue46998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46998] Allow subclassing Any at runtime
New submission from Shantanu : Discussed on typing-sig at https://mail.python.org/archives/list/typing-...@python.org/thread/GULRKYI7XOB3FLAEFC6OYSTBS5FIA5PU/ -- components: Library (Lib) messages: 415023 nosy: JelleZijlstra, hauntsaninja priority: normal severity: normal status: open title: Allow subclassing Any at runtime versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46831] Outdated comment for __build_class__ in compile.c
Change by Shantanu : -- keywords: +patch pull_requests: +29649 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31522 ___ Python tracker <https://bugs.python.org/issue46831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46831] Outdated comment for __build_class__ in compile.c
New submission from Shantanu : https://github.com/python/cpython/blob/cf345e945f48f54785799390c2e92c5310847bd4/Python/compile.c#L2537 ``` /* ultimately generate code for: = __build_class__(, , *, **) where: is a function/closure created from the class body; it has a single argument (__locals__) where the dict (or MutableSequence) representing the locals is passed ``` `func` currently takes zero arguments. This was changed in https://github.com/python/cpython/commit/e8e14591ebb729b4fa19626ce245fa0811cf6f32 in Python 3.4 -- assignee: docs@python components: Documentation messages: 413768 nosy: docs@python, hauntsaninja priority: normal severity: normal status: open title: Outdated comment for __build_class__ in compile.c ___ Python tracker <https://bugs.python.org/issue46831> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Shantanu added the comment: This is now PEP 680: https://www.python.org/dev/peps/pep-0680/ Currently being discussed at: https://discuss.python.org/t/pep-680-tomllib-support-for-parsing-toml-in-the-standard-library/13040 -- ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Shantanu added the comment: We've started a PEP draft. https://github.com/hauntsaninja/peps/blob/toml-pep/pep-.rst shows a rendered version. https://github.com/hauntsaninja/peps/pull/1 is a PR from the toml-pep branch to main, to help ease of review / discussion. If you're following along and need to get your bearings straight, here are the recently active locations of discussion: - this issue - https://github.com/hukkin/tomli/issues/141 - https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068/84 - https://github.com/hauntsaninja/peps/pull/1 -- ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Shantanu added the comment: pradyunsg kindly pointed me to an ongoing thread in Packaging discuss: https://discuss.python.org/t/adopting-recommending-a-toml-parser/4068/84 So seems like a PEP will be necessary. I'm happy to do legwork for that. (The PEP that I'll write differs from YakoYakoYokuYoku's json-esque draft in that it'll be based on tomli instead of a from-scratch implementation) -- ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Shantanu added the comment: > You will need to address where the code is coming from, why that code should > be used, what's the API, etc. Happy new year, potentially-toml-wanting friends! I wrote up a draft of a proposal here: https://gist.github.com/hauntsaninja/9f136a5a60f63d8ca2cdfadb50edba44 I've passed it along to hukkin (author of tomli) for feedback. Once they reply, I'll send it to python-dev and the deluge of comments can get underway. If in the meantime anyone else has thoughts, I'd love to hear from you. -- ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Shantanu added the comment: Given that this currently seems blocked on the broad question of "how should additions and removals to the stdlib be managed", I'd like to not focus too hard just yet on the specifics of tomli. I assume it's unlikely, but for all we know, the SC could determine that all newly included modules have to be written from scratch, following along the lines of recent additions like zoneinfo, graphlib and importlib.metadata. There's a lot we could bikeshed or debate... e.g., it's not even clear to me what a toml package in the stdlib would be named, never mind what it means for an unreleased version of a commonly used third party toml package dropping support for an imminently EOL version of Python. I'm possibly totally out of line, but in my head, the process would look something like this: Step 1: Hear back from the SC about criteria and considerations for new modules in the stdlib Step 2: Determine whether a TOML library *in the abstract* is something that would meet the outlined criteria (potentially e.g. is this something we even want? is this something we can maintain?) Step 3: Determine if we have an implementation (written from scratch, copied, or derived from something pre-existing) that would meet the outlined criteria Step 4: Do all the rest of the work to meet the outlined criteria (potentially e.g. go through PEP process, create proposed impl, write a backport, bikeshed api and name, etc) I guess I have the following questions: - Is my understanding correct that this issue is blocked on SC guidance? - Is there anything we could do in advance of SC guidance that would be productive? Brett previously mentioned bringing it up with the author of tomli, as per https://github.com/hukkin/tomli/issues/141 they seem supportive - Is there a good place to follow along or be notified of SC thoughts? I see no mention of stdlib changes in https://github.com/python/steering-council and the discuss thread linked above seems to have petered out. -- ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Shantanu added the comment: Hopefully tomli being less than a year old should not be a blocker, after all, TOML v1.0.0 is itself less than a year old. Despite tomli being new code, it's pretty widely used. Reverse dependencies include pip, pytest, mypy, black, flit, coverage, setuptools-scm, cibuildwheel. All in all, it should be well proven in practice by the time it comes to make 3.11 stable. It also helps that it's easy to anticipate the interface: dump, dumps, load, loads. Overall, hopefully risk here should be well within the budget of a provisional module. That's all to say, if and when the Steering Council decides that there's work to be done here, let me know how I can help :-) -- ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40059] Provide a toml module in the standard library
Shantanu added the comment: I'd love it if we could make this happen for Python 3.11. What can I do to help, e.g. would it be helpful if I drafted a PEP? Several projects have switched to using tomli (https://github.com/hukkin/tomli), which is fully compatible with TOML v1.0.0 and is maybe 800 LoC with claimed 100% branch coverage. There's also tomlkit, which has been around for longer, but is perhaps larger and more feature-ful than we'd want in stdlib, e.g. it allows you to roundtrip dump and load TOML documents preserving comments, whitespace, etc. -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue40059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45121] Regression in 3.9.7 with typing.Protocol
Shantanu added the comment: Sorry if my message was confusing. Hopefully the following makes things clear: 3.9.6: snippet runs without error 3.9.7, with bpo-44806: (a probably reasonable) TypeError, but a breaking change main, with bpo-45081: RecursionError -- ___ Python tracker <https://bugs.python.org/issue45121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45121] Regression in 3.9.7 with typing.Protocol
Shantanu added the comment: As I mentioned in the post, bpo-45081 actually makes this issue worse, since we get a RecursionError. I think `TypeError: Protocols cannot be instantiated` is probably okay behaviour (as opposed to RecursionError), more just unfortunate that it seems to be an unanticipated breaking change. -- ___ Python tracker <https://bugs.python.org/issue45121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45121] Regression in 3.9.7 with typing.Protocol
Change by Shantanu : -- nosy: +lukasz.langa ___ Python tracker <https://bugs.python.org/issue45121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45121] Regression in 3.9.7 with typing.Protocol
New submission from Shantanu :
Consider:
```
from typing import Protocol
class P(Protocol):
...
class C(P):
def __init__(self):
super().__init__()
C()
```
This code passes without error on 3.9.6.
With 3.9.7, we get:
```
Traceback (most recent call last):
File "/Users/shantanu/dev/test.py", line 10, in
C()
File "/Users/shantanu/dev/test.py", line 8, in __init__
super().__init__()
File "/Users/shantanu/.pyenv/versions/3.9.7/lib/python3.9/typing.py", line
1083, in _no_init
raise TypeError('Protocols cannot be instantiated')
TypeError: Protocols cannot be instantiated
```
I bisected this to:
bpo-44806: Fix __init__ in subclasses of protocols (GH-27545) (GH-27559)
Note there is also an interaction with the later commit:
bpo-45081: Fix __init__ method generation when inheriting from Protocol
(GH-28121) (GH-28132)
This later commit actually causes a RecursionError:
```
File "/Users/shantanu/dev/cpython/Lib/typing.py", line 1103, in
_no_init_or_replace_init
cls.__init__(self, *args, **kwargs)
File "/Users/shantanu/dev/test.py", line 8, in __init__
super().__init__()
File "/Users/shantanu/dev/cpython/Lib/typing.py", line 1103, in
_no_init_or_replace_init
cls.__init__(self, *args, **kwargs)
File "/Users/shantanu/dev/test.py", line 8, in __init__
super().__init__()
```
Originally reported by @tyralla on Gitter.
--
components: Library (Lib)
messages: 401184
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Regression in 3.9.7 with typing.Protocol
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue45121>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38250] enum.Flag should be more set-like
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 6.0 -> 7.0 pull_requests: +24506 pull_request: https://github.com/python/cpython/pull/25820 ___ Python tracker <https://bugs.python.org/issue38250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44006] symbol documentation still exists
Shantanu added the comment: Do you see what's generating it? As far as I can tell, the RST was removed a while ago in https://github.com/python/cpython/pull/21624 -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue44006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43798] Add position metadata to alias AST type
Shantanu added the comment: FYI, probably unavoidable, but this appears to have broken pytest https://github.com/pytest-dev/pytest/issues/8539 -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue43798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16396] Importing ctypes.wintypes on Linux gives a ValueError instead of an ImportError
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 12.0 -> 13.0 pull_requests: +22798 pull_request: https://github.com/python/cpython/pull/23951 ___ Python tracker <https://bugs.python.org/issue16396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39791] New `files()` api from importlib_resources.
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 8.0 -> 9.0 pull_requests: +22577 pull_request: https://github.com/python/cpython/pull/23715 ___ Python tracker <https://bugs.python.org/issue39791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42195] Inconsistent __args__ between typing.Callable and collections.abc.Callable
Shantanu added the comment: You're right that Callable[[P], int] is invalid, so a flat representation isn't currently ambiguous. But a flat representation would foist the responsibility for checking that to all users of `__args__`. If your code isn't ParamSpec aware, your failures will probably be less obvious or even silent. The flat representation trades off a) implementation complexity with b) usability / aesthetics, c) future proof-ness. I'm not morally opposed to such a tradeoff / am happy to defer to people with more experience in making such tradeoffs. -- ___ Python tracker <https://bugs.python.org/issue42195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42195] Inconsistent __args__ between typing.Callable and collections.abc.Callable
Shantanu added the comment: I think ((int, int), str) is superior to the others and if it can be made to work, that's what we should do. Note that if variadic type proposals go anywhere (https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXsE318/edit#), my understanding is we'd probably have to loosen the assumption that __args__ only contains types for that to work too. (int, int, str) is temptingly easy, but I think it's a bad idea. For starters, PEP 612 loosens what X can be in Callable[X, str] and life is too short to spend time figuring out whether (P, str) is meant to be Callable[P, str] or Callable[[P], str]. I'm still trying to figure out how I feel about (Tuple[int, int], str). My initial reaction was negative / I think I'd be more comfortable with a (_Posargs[int, int], str). I don't think Tuple[int, int] would be a workable solution in the event that variadic types pose a similar problem. -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue42195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42102] Make builtins.callable "generic"
Shantanu added the comment: My implementation in PR 22848 turns callable into a type and uses `__new__`. It isn't too bad. It does appear to affect performance of callable though. Here's some data on how often typing imports are used. This is the number of files in which `from typing import X` is present in mypy_primer's corpus (searched using the AST). My read of this is that Callable is meaningfully more used than anything else in collections.abc. ``` 'Optional': 2563 'Any': 2402 'List': 2383 'Dict': 2150 'Tuple': 1592 'Union': 1269 'Callable': 1058 'Iterable': 609 'Set': 580 'cast': 505 'Sequence': 465 'Type': 438 'Iterator': 385 'TYPE_CHECKING': 357 'TypeVar': 302 'Mapping': 301 'Generator': 194 'NamedTuple': 138 'Text': 127 'IO': 120 'Awaitable': 116 ... ``` -- ___ Python tracker <https://bugs.python.org/issue42102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42102] Make builtins.callable "generic"
Shantanu added the comment:
Sure, I put together a draft PR here:
https://github.com/python/cpython/pull/22848 Tests pass cleanly, though timeit
indicates callable is slower.
I haven't added instancecheck, which we should consider doing, since
`isinstance(x, callable)` would now return False, instead of raising TypeError.
@serhiy
I hack around that using `callable.__new__`, so `callable[[int], str]()` raises
a TypeError in my draft PR. Note that `callable[[int], str](f)` would work the
same as `callable(f)` does today (which from a typechecking perspective is
similar to the fact that `list[int](("a", "b", "c"))` works).
I agree that callable being a predicate means that there probably isn't an
aesthetically pleasing way of doing this.
@kj
I'm a little out of my comfort zone, so please let me know if you see a better
way of doing things :-)
--
___
Python tracker
<https://bugs.python.org/issue42102>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42102] Make builtins.callable "generic"
Change by Shantanu : -- keywords: +patch pull_requests: +21796 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22848 ___ Python tracker <https://bugs.python.org/issue42102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42102] Make builtins.callable "generic"
New submission from Shantanu : In the post PEP 585 world, it seems like a bit of a stumbling block for builtins.callable to not able to be parametrised (in a runtime context). Post PEP 604, I'd expect typing.Callable to be the most used typing import after typing.Any, so much of PEP 585's rationale should apply to this case too. Concretely, one way to implement this would be to turn callable into a type whose __new__ returns a bool and which implements __class_getitem__. We could throw in an __instancecheck__ so that `isinstance(x, callable) == callable(x)`. PS: Despite being code that crashes instantly, I was still able to find some instances of `isinstance(x, callable)` on popular Github projects: https://grep.app/search?q=isinstance%5C%28.%2A%2C%20callable%5C%29=true=true -- messages: 379169 nosy: hauntsaninja priority: normal severity: normal status: open title: Make builtins.callable "generic" type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28002] ast.unparse can't roundtrip some f-strings
Shantanu added the comment: Bumping again! -- ___ Python tracker <https://bugs.python.org/issue28002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41696] asyncio.run interacts surprisingly with debug mode
Change by Shantanu : -- keywords: +patch pull_requests: +21159 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22069 ___ Python tracker <https://bugs.python.org/issue41696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41696] asyncio.run interacts surprisingly with debug mode
New submission from Shantanu : To quote the docs (https://docs.python.org/3/library/asyncio-dev.html): ``` By default asyncio runs in production mode. In order to ease the development asyncio has a debug mode. There are several ways to enable asyncio debug mode: Setting the PYTHONASYNCIODEBUG environment variable to 1. Using the -X dev Python command line option. Passing debug=True to asyncio.run(). Calling loop.set_debug(). ``` Unfortunately, this documentation is misleading (or wrong) when using asyncio.run. For instance, from a naive read of the above, I'd expect debug mode to be True for many of the following: ``` ~/tmp λ cat test57.py import asyncio import time async def foo(): loop = asyncio.get_event_loop() time.sleep(2) print(loop.get_debug()) print(asyncio.coroutines._DEBUG) asyncio.run(foo()) ~/tmp λ python3 --version Python 3.7.3 # expected ~/tmp λ python3 test57.py False False # surprising, would expect this to work ~/tmp λ python3 -X dev test57.py True False # surprising, would expect this to work ~/tmp λ PYTHONASYNCIODEBUG=1 python3 test57.py True False # expected ~/tmp λ vim test57.py ~/tmp λ cat test57.py import asyncio import time async def foo(): loop = asyncio.get_event_loop() time.sleep(2) print(loop.get_debug()) print(asyncio.coroutines._DEBUG) asyncio.run(foo(), debug=True) ~/tmp λ python3 test57.py False True Executing result=None created at /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py:563> took 2.003 seconds ~/tmp λ ``` This appears to be because asyncio.run sets debug mode here: https://github.com/python/cpython/blob/4a97b1517a6b5ff22e2984b677a680b07ff0ce11/Lib/asyncio/runners.py#L42 We should either change asyncio.run to use the existing value of debug mode if left unspecified, or we should update the documentation to explicitly call out that the environment variable and command line flag will not work when using asyncio.run -- components: asyncio messages: 376268 nosy: asvetlov, hauntsaninja, yselivanov priority: normal severity: normal status: open title: asyncio.run interacts surprisingly with debug mode ___ Python tracker <https://bugs.python.org/issue41696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()
Change by Shantanu : -- pull_requests: +21145 pull_request: https://github.com/python/cpython/pull/22048 ___ Python tracker <https://bugs.python.org/issue39349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()
Change by Shantanu : -- pull_requests: +21123 pull_request: https://github.com/python/cpython/pull/22023 ___ Python tracker <https://bugs.python.org/issue39349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()
Shantanu added the comment: I was working on updating typeshed stubs to reflect this change. It looks like the parameter wasn't actually added to the base class (https://github.com/python/cpython/blob/c3a651ad2544d7d1be389b63e9a4a58a92a31623/Lib/concurrent/futures/_base.py#L608), even though it's documented as having the new parameter (https://docs.python.org/3.9/library/concurrent.futures.html#concurrent.futures.Executor.shutdown). Is this intentional? If not, I'd be happy to submit a PR adding the parameter to the base class. -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue39349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28724] Add method send_io, recv_io to the socket module.
Shantanu added the comment: I was looking at adding stubs for these to typeshed. Is it intentional that we ignore the flags and address arguments in the implementation? -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue28724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28002] ast.unparse can't roundtrip some f-strings
Shantanu added the comment: Just bumping this issue, as per dev guide, since https://github.com/python/cpython/pull/19612 has been ready for about two months. Would be grateful for review :-) -- ___ Python tracker <https://bugs.python.org/issue28002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40614] ast.parse doesn't respect feature_version for debug f-strings
Change by Shantanu : -- pull_requests: +19718 pull_request: https://github.com/python/cpython/pull/20466 ___ Python tracker <https://bugs.python.org/issue40614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20928] xml.etree.ElementInclude does not include nested xincludes
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 8.0 -> 9.0 pull_requests: +19695 pull_request: https://github.com/python/cpython/pull/20438 ___ Python tracker <https://bugs.python.org/issue20928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33187] Document ElementInclude (XInclude) support in ElementTree
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 6.0 -> 7.0 pull_requests: +19694 pull_request: https://github.com/python/cpython/pull/20438 ___ Python tracker <https://bugs.python.org/issue33187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 5.0 -> 6.0 pull_requests: +19505 pull_request: https://github.com/python/cpython/pull/20208 ___ Python tracker <https://bugs.python.org/issue20177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40676] Use Argument Clinic for csv
Change by Shantanu : -- keywords: +patch pull_requests: +19499 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20200 ___ Python tracker <https://bugs.python.org/issue40676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40676] Use Argument Clinic for csv
New submission from Shantanu : To do all the functions in csv, we'd need to have support for **kwargs, tracked in https://bugs.python.org/issue20291. Am attaching a PR for the ones that can be made to work today. -- components: Argument Clinic messages: 369314 nosy: hauntsaninja, larry priority: normal severity: normal status: open title: Use Argument Clinic for csv ___ Python tracker <https://bugs.python.org/issue40676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40614] ast.parse doesn't respect feature_version for debug f-strings
Change by Shantanu : -- keywords: +patch pull_requests: +19496 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20196 ___ Python tracker <https://bugs.python.org/issue40614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13601] sys.stderr should be line-buffered when stderr is not a TTY
Change by Shantanu : -- pull_requests: +19467 pull_request: https://github.com/python/cpython/pull/20168 ___ Python tracker <https://bugs.python.org/issue13601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40662] ast.get_source_segment behaviour with missing location info doesn't match docstring
Shantanu added the comment: The code works on 3.8 for me, but has regressed on 3.9 master. Looks like this is caused by https://bugs.python.org/issue36287 (https://github.com/python/cpython/pull/18843) -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue40662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40665] Use Argument Clinic for bisect
Change by Shantanu : -- keywords: +patch pull_requests: +19463 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20163 ___ Python tracker <https://bugs.python.org/issue40665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40665] Use Argument Clinic for bisect
New submission from Shantanu : As the title says! Am submitting a PR. -- components: Argument Clinic messages: 369153 nosy: hauntsaninja, larry priority: normal severity: normal status: open title: Use Argument Clinic for bisect ___ Python tracker <https://bugs.python.org/issue40665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34556] Add --upgrade-deps to venv module
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 4.0 -> 5.0 pull_requests: +19440 pull_request: https://github.com/python/cpython/pull/20135 ___ Python tracker <https://bugs.python.org/issue34556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13601] sys.stderr should be line-buffered when stderr is not a TTY
Shantanu added the comment: I'm wondering if this should be mentioned in Python 3.9's What's New, potentially at https://docs.python.org/3.9/whatsnew/3.9.html#sys ? This change broke one of mypy's tests on 3.9 and it was a little tricky to find what had changed. -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue13601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40586] Pydoc should support https for hyperlinks.
Shantanu added the comment: This looks like a duplicate of https://bugs.python.org/issue38786, which was fixed in https://github.com/python/cpython/pull/17143 That PR wasn't backported, but maybe it should be. -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue40586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40495] compileall: option to hardlink duplicate optimization levels bytecode cache files
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 6.0 -> 7.0 pull_requests: +19428 pull_request: https://github.com/python/cpython/pull/19806 ___ Python tracker <https://bugs.python.org/issue40495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40621] Python crashes with new parser on invalid exception handlers
Change by Shantanu : -- keywords: +patch pull_requests: +19390 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20086 ___ Python tracker <https://bugs.python.org/issue40621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40621] Python crashes with new parser on invalid exception handlers
New submission from Shantanu : ``` ~/dev/cpython master λ ./python.exe --version --version Python 3.9.0a6+ (heads/master:a15c9b3a05, May 14 2020, 00:31:47) [Clang 11.0.0 (clang-1100.0.33.17)] # should raise a syntax error, instead crashes ~/dev/cpython master λ cat test.py try: 1 / 0 except Exception as a.b: pass ~/dev/cpython master λ ./python.exe test.py [1]63986 bus error ./python.exe test.py ~/dev/cpython master λ ./python.exe -Xoldparser test.py File "/Users/shantanu/dev/cpython/test.py", line 3 except Exception as a.b: ^ SyntaxError: invalid syntax # should raise a syntax error, instead passes ~/dev/cpython master λ cat test2.py try: 1 / 0 except Exception as (a): pass ~/dev/cpython master λ ./python.exe test2.py ~/dev/cpython master λ ./python.exe -Xoldparser test2.py File "/Users/shantanu/dev/cpython/test2.py", line 3 except Exception as (a): ^ SyntaxError: invalid syntax # should raise a syntax error, instead crashes ~/dev/cpython master λ cat test3.py try: 1 / 0 except Exception as a[0]: pass ~/dev/cpython master λ ./python.exe test3.py [1]64206 bus error ./python.exe test3.py ~/dev/cpython master λ ./python.exe -Xoldparser test3.py File "/Users/shantanu/dev/cpython/test3.py", line 3 except Exception as a[0]: ^ SyntaxError: invalid syntax ``` The old grammar expects a NAME here, but the new grammar attempts to use a target (https://docs.python.org/3/reference/grammar.html). Seems like we should just go back to using NAME. -- messages: 368818 nosy: hauntsaninja priority: normal severity: normal status: open title: Python crashes with new parser on invalid exception handlers ___ Python tracker <https://bugs.python.org/issue40621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40614] ast.parse doesn't respect feature_version for debug f-strings
New submission from Shantanu :
```
~master λ python3.8
Python 3.8.2 (default, Apr 21 2020, 00:39:48)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse('''f"{x=}"''') # should work
<_ast.Module object at 0x10f81af40>
>>> ast.parse('''f"{x=}"''', feature_version=(3, 6)) # should fail, but doesn't
<_ast.Module object at 0x10f857d00>
```
--
messages: 368763
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: ast.parse doesn't respect feature_version for debug f-strings
type: behavior
___
Python tracker
<https://bugs.python.org/issue40614>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40334] PEP 617: new PEG-based parser
Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 7.0 -> 8.0 pull_requests: +19226 pull_request: https://github.com/python/cpython/pull/19911 ___ Python tracker <https://bugs.python.org/issue40334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40493] Pegen can't parse some function type comments
Change by Shantanu : -- keywords: +patch pull_requests: +19205 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19894 ___ Python tracker <https://bugs.python.org/issue40493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40493] Pegen can't parse some function type comments
New submission from Shantanu :
Currently fails if we don't have any arguments before *args and **kwargs
```
~ λ python3.9
Python 3.9.0a6+ (heads/master:c95e691, May 3 2020, 19:57:46)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast; ast.parse("(*int) -> None", mode="func_type",
>>> type_comments=True)
Traceback (most recent call last):
File "", line 1, in
File "/Users/shantanu/.pyenv/versions/3.9-dev/lib/python3.9/ast.py", line 50,
in parse
return compile(source, filename, mode, flags,
File "", line 1
(*int) -> None
^
SyntaxError: invalid syntax
```
--
messages: 368009
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Pegen can't parse some function type comments
___
Python tracker
<https://bugs.python.org/issue40493>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40491] Typo in SyntaxError produced by pegen for numeric literals
Change by Shantanu : -- keywords: +patch pull_requests: +19204 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19893 ___ Python tracker <https://bugs.python.org/issue40491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40491] Typo in SyntaxError produced by pegen for numeric literals
New submission from Shantanu :
```
~ λ python3.9
Python 3.9.0a6+ (heads/master:c95e691, May 3 2020, 19:57:46)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse("1_2", feature_version=(3, 5))
Traceback (most recent call last):
File "", line 1, in
File "/Users/shantanu/.pyenv/versions/3.9-dev/lib/python3.9/ast.py", line 50,
in parse
return compile(source, filename, mode, flags,
File "", line 1
1_2
^
SyntaxError: Underscores in numeric literals are only supportedin Python 3.6
and greater
```
--
messages: 368006
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Typo in SyntaxError produced by pegen for numeric literals
___
Python tracker
<https://bugs.python.org/issue40491>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39691] Allow passing Pathlike objects to io.open_code
Change by Shantanu : -- keywords: +patch nosy: +hauntsaninja nosy_count: 3.0 -> 4.0 pull_requests: +19145 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19824 ___ Python tracker <https://bugs.python.org/issue39691> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40447] compile_file's stripdir does not accept pathlib.Path
Shantanu added the comment: If it helps triage, this is the BPO for where the changes to compileall were made: https://bugs.python.org/issue38112 -- ___ Python tracker <https://bugs.python.org/issue40447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40447] compile_file's stripdir does not accept pathlib.Path
New submission from Shantanu :
Python 3.9 added the stripdir argument to compileall functions. From
https://docs.python.org/3.9/library/compileall.html#compileall.compile_file:
> The stripdir, prependdir and limit_sl_dest arguments correspond to the -s, -p
> and -e options described above. They may be specified as str, bytes or
> os.PathLike.
```
~ λ python3.9
Python 3.9.0a6+ (heads/master:360371f, Apr 29 2020, 15:44:56)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import compileall, pathlib
>>> compileall.compile_file(pathlib.Path("tmp/test.py"),
>>> stripdir=pathlib.Path("tmp"))
Traceback (most recent call last):
File "", line 1, in
File "/Users/shantanu/.pyenv/versions/3.9-dev/lib/python3.9/compileall.py",
line 161, in compile_file
stripdir_parts = stripdir.split(os.path.sep)
AttributeError: 'PosixPath' object has no attribute 'split'
```
Found by Jelle Zijlstra in
https://github.com/python/typeshed/pull/3956#discussion_r417735663
--
components: Library (Lib)
messages: 367740
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: compile_file's stripdir does not accept pathlib.Path
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40447>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40445] compileall.compile_dir docs aren't updated for bpo-38112
Change by Shantanu : -- keywords: +patch pull_requests: +19127 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19806 ___ Python tracker <https://bugs.python.org/issue40445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40445] compileall.compile_dir docs aren't updated for bpo-38112
New submission from Shantanu : While the signature was updated in the documentation, the text below wasn't, and still reflects the old default of 10. https://docs.python.org/3.9/library/compileall.html#compileall.compile_dir -- assignee: docs@python components: Documentation messages: 367714 nosy: docs@python, hauntsaninja priority: normal severity: normal status: open title: compileall.compile_dir docs aren't updated for bpo-38112 versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40222] "Zero cost" exception handling
Change by Shantanu : -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue40222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40349] Python3.9 changes col_offset for some ast nodes
New submission from Shantanu :
With Python 3.8:
```
Python 3.8.1 (default, Jan 23 2020, 23:36:06)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse("(a).x").body[0].value.col_offset
1
```
With Python 3.9:
```
Python 3.9.0a5+ (heads/master:799d7d6, Apr 6 2020, 16:05:37)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse("(a).x").body[0].value.col_offset
0
```
Maybe related to the new parser? I couldn't find what the environment variable
to turn it off was.
For context, I'm trying to get mypy tests to pass with 3.9, but the tests make
use of specific col_offsets for error reporting. It would be nice if these
continued to match with 3.9
--
messages: 366909
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Python3.9 changes col_offset for some ast nodes
___
Python tracker
<https://bugs.python.org/issue40349>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28002] ast.unparse can't roundtrip some f-strings
Change by Shantanu : -- keywords: +patch pull_requests: +18946 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19612 ___ Python tracker <https://bugs.python.org/issue28002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28002] ast.unparse can't roundtrip some f-strings
Shantanu added the comment: Now that `ast.unparse` is being added to stdlib, I thought I'd bump this thread. The third party library `astunparse` (which attempts to support multiple Python versions while staying very close to Tools/parser/unparse.py) has an implementation that works for complex cases. If that sounds good, I can submit a PR and inform the original author (astunparse is license is based on PSF's, so should be okay if the original author doesn't respond). https://github.com/simonpercivall/astunparse/blob/master/lib/astunparse/unparser.py#L461 -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue28002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39722] decimal differs between pure Python and C implementations
Shantanu added the comment: Sounds good, thought I'd check! :-) Definitely looks annoying to remove from the Python version too. -- ___ Python tracker <https://bugs.python.org/issue39722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39723] io.open_code should accept PathLike objects
Change by Shantanu : -- keywords: +patch pull_requests: +17969 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18602 ___ Python tracker <https://bugs.python.org/issue39723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39723] io.open_code should accept PathLike objects
New submission from Shantanu : Currently io.open_code (added in Python 3.8) only accepts str arguments. As per PEP 519, it should probably also accept PathLike. It might be worth extending it to accept bytes as well, both for convenience and because documentation claims it should be interchangeable with ``open(path, 'rb')``. https://github.com/python/cpython/blob/3.8/Modules/_io/_iomodule.c#L510 -- components: Library (Lib) messages: 362446 nosy: hauntsaninja priority: normal severity: normal status: open title: io.open_code should accept PathLike objects type: enhancement ___ Python tracker <https://bugs.python.org/issue39723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39722] decimal differs between pure Python and C implementations
New submission from Shantanu :
The dunder methods on decimal.Decimal accept an extra context argument in the
pure Python version which the C version does not (violating PEP 399).
This came up in https://github.com/python/typeshed/pull/3633, where Sebastian
provided the following summary of the issue:
```
Python 3.8.1 (default, Jan 14 2020, 19:41:43)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from _decimal import Decimal as CDecimal
>>> from _pydecimal import Decimal as PyDecimal
>>> PyDecimal(1).__abs__(None)
Decimal('1')
>>> CDecimal(1).__abs__(None)
Traceback (most recent call last):
File "", line 1, in
TypeError: expected 0 arguments, got 1
```
--
components: Library (Lib)
messages: 362443
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: decimal differs between pure Python and C implementations
___
Python tracker
<https://bugs.python.org/issue39722>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39719] tempfile.SpooledTemporaryFile still has softspace property
Change by Shantanu : -- keywords: +patch pull_requests: +17966 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18599 ___ Python tracker <https://bugs.python.org/issue39719> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39719] tempfile.SpooledTemporaryFile still has softspace property
New submission from Shantanu : The softspace attribute of files was removed in Python 3 (mentioned in https://raw.githubusercontent.com/python/cpython/master/Misc/HISTORY) However, tempfile.SpooledTemporaryFile still has a softspace property that attempts to return read the softspace attribute. ``` In [23]: t = tempfile.SpooledTemporaryFile() In [24]: t.softspace --- AttributeErrorTraceback (most recent call last) in > 1 t.softspace /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/tempfile.py in softspace(self) 749 @property 750 def softspace(self): --> 751 return self._file.softspace 752 753 def tell(self): AttributeError: '_io.BytesIO' object has no attribute 'softspace' ``` -- messages: 362437 nosy: hauntsaninja priority: normal severity: normal status: open title: tempfile.SpooledTemporaryFile still has softspace property ___ Python tracker <https://bugs.python.org/issue39719> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39718] TYPE_IGNORE, COLONEQUAL missing from py38 changes in token docs
Change by Shantanu : -- keywords: +patch pull_requests: +17965 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18598 ___ Python tracker <https://bugs.python.org/issue39718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39718] TYPE_IGNORE, COLONEQUAL missing from py38 changes in token docs
New submission from Shantanu : Changed in version 3.8 section of https://docs.python.org/3/library/token.html should mention the addition of TYPE_IGNORE and COLONEQUAL -- assignee: docs@python components: Documentation messages: 362436 nosy: docs@python, hauntsaninja priority: normal severity: normal status: open title: TYPE_IGNORE, COLONEQUAL missing from py38 changes in token docs ___ Python tracker <https://bugs.python.org/issue39718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39559] uuid.getnode() has unused argument
Shantanu added the comment: Github code search isn't great, but I was unable to find any usage of `uuid.getnode(getters=`, whereas I was able to find usage of `uuid.uuid1(node=` (even though `node` is optional and can be passed positionally). I'd be surprised if it was used in practice, given that it's undocumented and only present on 3.7+ (I discovered it while running `inspect.signature` on large parts of stdlib). I think that, and the fact that this never did anything (even before bpo-28009 it looks like `getters` gets immediately overwritten), mitigate the risk here. Let me know what you think should be done; happy to submit a PR that issues a deprecation warning. -- nosy: +hauntsaninja ___ Python tracker <https://bugs.python.org/issue39559> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39559] uuid.getnode() has unused argument
Change by Shantanu : -- keywords: +patch pull_requests: +17743 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18369 ___ Python tracker <https://bugs.python.org/issue39559> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28009] Fix uuid.uuid1() core logic of uuid.getnode() needs refresh
Change by Shantanu : -- pull_requests: +17744 pull_request: https://github.com/python/cpython/pull/18369 ___ Python tracker <https://bugs.python.org/issue28009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39504] inspect.signature throws RuntimeError on select.epoll.register
New submission from Shantanu : >From the documentation of `inspect.signature` it seems we should never have a >RuntimeError: ``` Raises ValueError if no signature can be provided, and TypeError if that type of object is not supported. ``` The easiest thing to do is just turn the RuntimeError into a ValueError... but I'll take a deeper look and see if I can actually fix this. Traceback below: ``` >>> import sys >>> sys.version '3.8.0 (default, Nov 14 2019, 22:29:45) \n[GCC 5.4.0 20160609]' >>> import inspect >>> import select >>> inspect.signature(select.epoll.register) Traceback (most recent call last): File "/usr/lib/python3.8/inspect.py", line 2004, in wrap_value value = eval(s, module_dict) File "", line 1, in NameError: name 'EPOLLIN' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.8/inspect.py", line 2007, in wrap_value value = eval(s, sys_module_dict) File "", line 1, in NameError: name 'EPOLLIN' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.8/inspect.py", line 3093, in signature return Signature.from_callable(obj, follow_wrapped=follow_wrapped) File "/usr/lib/python3.8/inspect.py", line 2842, in from_callable return _signature_from_callable(obj, sigcls=cls, File "/usr/lib/python3.8/inspect.py", line 2296, in _signature_from_callable return _signature_from_builtin(sigcls, obj, File "/usr/lib/python3.8/inspect.py", line 2109, in _signature_from_builtin return _signature_fromstr(cls, func, s, skip_bound_arg) File "/usr/lib/python3.8/inspect.py", line 2057, in _signature_fromstr p(name, default) File "/usr/lib/python3.8/inspect.py", line 2039, in p default_node = RewriteSymbolics().visit(default_node) File "/usr/lib/python3.8/ast.py", line 360, in visit return visitor(node) File "/usr/lib/python3.8/ast.py", line 445, in generic_visit new_node = self.visit(old_value) File "/usr/lib/python3.8/ast.py", line 360, in visit return visitor(node) File "/usr/lib/python3.8/ast.py", line 445, in generic_visit new_node = self.visit(old_value) File "/usr/lib/python3.8/ast.py", line 360, in visit return visitor(node) File "/usr/lib/python3.8/inspect.py", line 2031, in visit_Name return wrap_value(node.id) File "/usr/lib/python3.8/inspect.py", line 2009, in wrap_value raise RuntimeError() RuntimeError ``` -- components: Library (Lib) messages: 361089 nosy: hauntsaninja priority: normal severity: normal status: open title: inspect.signature throws RuntimeError on select.epoll.register ___ Python tracker <https://bugs.python.org/issue39504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations
Change by Shantanu : -- keywords: +patch pull_requests: +17650 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18275 ___ Python tracker <https://bugs.python.org/issue39495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations
Shantanu added the comment:
Based on
https://github.com/python/cpython/blob/master/Modules/_elementtree.c#L2700 and
the behaviour at runtime, something like the following patch could work:
```
diff --git a/Lib/xml/etree/ElementTree.py b/Lib/xml/etree/ElementTree.py
index c8d898f328..bbfc1afe08 100644
--- a/Lib/xml/etree/ElementTree.py
+++ b/Lib/xml/etree/ElementTree.py
@@ -1452,7 +1452,7 @@ class TreeBuilder:
"""Add text to current element."""
self._data.append(data)
-def start(self, tag, attrs):
+def start(self, tag, attrs=None):
"""Open new element and return it.
*tag* is the element name, *attrs* is a dict containing element
@@ -1460,6 +1460,8 @@ class TreeBuilder:
"""
self._flush()
+if attrs is None:
+attrs = {}
self._last = elem = self._factory(tag, attrs)
if self._elem:
self._elem[-1].append(elem)
```
Happy to submit a PR!
--
___
Python tracker
<https://bugs.python.org/issue39495>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39495] xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations
New submission from Shantanu :
The C accelerated version of `xml.etree.ElementTree.TreeBuilder.start` has a
default value for `attrs`, whereas the pure Python version does not.
```
In [41]: sys.version
Out[41]: '3.8.1 (default, Jan 23 2020, 23:36:06) \n[Clang 11.0.0
(clang-1100.0.33.17)]'
In [42]: import xml.etree.ElementTree
In [43]: inspect.signature(xml.etree.ElementTree.TreeBuilder.start)
Out[43]:
In [44]: from test.support import import_fresh_module
In [45]: pyElementTree = import_fresh_module('xml.etree.ElementTree',
blocked=['_elementtree'])
In [46]: inspect.signature(pyElementTree.TreeBuilder.start)
Out[46]:
```
>From PEP 399 (https://www.python.org/dev/peps/pep-0399/)
```
Acting as a drop-in replacement also dictates that no public API be provided in
accelerated code that does not exist in the pure Python code. Without this
requirement people could accidentally come to rely on a detail in the
accelerated code which is not made available to other VMs that use the pure
Python implementation.
```
--
components: Library (Lib)
messages: 361002
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.TreeBuilder.start differs between pure Python and
C implementations
___
Python tracker
<https://bugs.python.org/issue39495>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39493] typing.py has an incorrect definition of closed
Change by Shantanu : -- keywords: +patch pull_requests: +17642 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18265 ___ Python tracker <https://bugs.python.org/issue39493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39493] typing.py has an incorrect definition of closed
New submission from Shantanu :
Hello!
typing.py has the following definition of `closed`:
https://github.com/python/cpython/blob/master/Lib/typing.py#L1834
```
@abstractmethod
def closed(self) -> bool:
pass
```
This is inconsistent with the behaviour at runtime:
```
In [17]: sys.version
Out[17]: '3.8.1 (default, Jan 23 2020, 23:36:06) \n[Clang 11.0.0
(clang-1100.0.33.17)]'
In [18]: f = open("test", "w")
In [19]: f.closed
Out[19]: False
```
It seems like the right thing to do is add an @property, as we do with e.g.
`mode` and `name`. I'll submit a PR with this change.
Note typeshed also types this as a property to indicate a read-only attribute.
https://github.com/python/typeshed/blob/master/stdlib/3/typing.pyi#L459
First time filing a bug on BPO, thanks a lot in advance!
--
messages: 360996
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: typing.py has an incorrect definition of closed
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue39493>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
