[issue46820] SyntaxError on `1not in...`
New submission from Patrick Reader : The following code gives a SyntaxError in 3.10, but used to work fine before (I have tested it in 2.7, 3.8, 3.9): 1not in [2, 3] It seems to be only the `not in` syntax which is affected; all other keywords still work correctly: 1in [2, 3] 1or 2 1and 2 1if 1else 1 1is 1 I know this syntax is deprecated in 3.10 (bpo43833), but it still needs to work for now, so that old code written like this can keep working. -- components: Parser messages: 413664 nosy: lys.nikolaou, pablogsal, pxeger priority: normal severity: normal status: open title: SyntaxError on `1not in...` type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47147] Allow `return yield from`
New submission from Patrick Reader : I would like to be able to use a `yield from` expression in a `return` statement without parentheses, as a small quality of life tweak, i.e.: return yield from gen instead of return (yield from gen) I think this makes sense, since `yield from` can be used on the right-hand-side of an assignment, which accepts any expression, and so should `return`. Here is a medium-sized real-world example of where I'm using this, where it would be nice to allow `return yield from`: https://gist.github.com/pxeger/48f97484364bf0b43dee974a8f0f4265 -- components: Parser messages: 416198 nosy: lys.nikolaou, pablogsal, pxeger priority: normal severity: normal status: open title: Allow `return yield from` type: enhancement ___ Python tracker <https://bugs.python.org/issue47147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47147] Allow `return yield from`
Patrick Reader added the comment: Ok, will do, but what is the bar for a feature to need to go to the mailing lists first? I thought as this was a relatively minor one it wouldn't need to. Is it just because it's an actual syntax change? -- ___ Python tracker <https://bugs.python.org/issue47147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47147] Allow `return yield from`
Patrick Reader added the comment: As the one who wrote the code, I can guarantee you that the StopIteration value is not always None. But I understand your point that for most other users it is always None, and therefore having special syntax might be misleading. -- ___ Python tracker <https://bugs.python.org/issue47147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43480] Add .path method/property to tempfile.* for a pathlib.Path
New submission from Patrick Reader : It would be nice to have a `.path` method or property on `tempfile.NamedTemporaryFile`, `tempfile.TemporaryDirectory` which produces a `pathlib.Path` of their `.name` attribute, so one can use the modern interface directly. I think a method would be more appropriate than a property because you're explicitly allocating a new object (unless you use `@functools.cached_property` or similar to have a shared object between successive calls) I can do a PR. -- components: Library (Lib) messages: 388540 nosy: pxeger priority: normal severity: normal status: open title: Add .path method/property to tempfile.* for a pathlib.Path type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43480> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43726] regex module fails with a quantified backref but succeeds with repeated backref
Patrick Reader added the comment: The `regex` module is a third-party package, not part of the Python standard library. Please report issues here: https://bitbucket.org/mrabarnett/mrab-regex/issues -- nosy: +pxeger ___ Python tracker <https://bugs.python.org/issue43726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Patrick Reader added the comment: I would like to note that syntax like this is in heavy use in the Code Golf community (a sport in which the aim is to write the shortest code possible to complete a particular task). It will be disappointing if it becomes an error and break many past programs (you can search for phrases like `1and`, `0for` on https://codegolf.stackexchange.com/search?q=0for for examples). I could understand if this change remains because code golf is not exactly an important thing with serious ramifications, but I think it should be taken in to consideration as a use-case nonetheless. -- nosy: +pxeger ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
New submission from Patrick Reader :
When a frame's __builtins__ is a subclass of dict with an overridden
__getitem__ method, this overriden method is not used by the IMPORT_NAME
instruction to lookup __import__ in the dictionary; it uses the lookup function
of normal dictionaries (via _PyDict_GetItemIdWithError). This is contrary to
the behaviour of the similar LOAD_BUILD_CLASS, as well as the typical name
lookup semantics of LOAD_GLOBAL/LOAD_NAME, which all use PyDict_CheckExact for
a "fast path" before defaulting to PyObject_GetItem, which is not the behaviour
I expected.
Perhaps more seriously, if __builtins__ is not a dict at all, then it gets
erroneously passed to some internal dict functions resulting in a mysterious
SystemError ("Objects/dictobject.c:1440: bad argument to internal function")
which, to me, indicates fragile behaviour that isn't supposed to happen.
Could this be changed, so that __builtins__ is used dynamically? I understand
this is a highly specific use case and changing it would probably cause a bit
of a slow-down in module importing so is perhaps not worth doing, but I've
posted this issue to track it anyway.
I cannot find evidence that this behaviour has changed at all in recent history
and it seems to be the same on the main branch as in 3.9.6.
Per a brief discussion with Brett Cannon on python-dev
(https://mail.python.org/archives/list/python-...@python.org/thread/ZQMF6XC76J4APJPB3X6PGATG6CV5NN44/),
I have labelled this a feature request because it has never really been
expected behaviour.
A short demo of these things is attached.
Links to relevant CPython code in v3.9.6:
IMPORT_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L5179
BUILD_CLASS: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2316
LOAD_NAME: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2488
LOAD_GLOBAL: https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2546
--
components: Interpreter Core
files: dict_lookup_demo.py
messages: 397531
nosy: brett.cannon, pxeger
priority: normal
severity: normal
status: open
title: importing does not dispatch to __builtins__.__getitem__ to lookup
__import__
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.9
Added file: https://bugs.python.org/file50151/dict_lookup_demo.py
___
Python tracker
<https://bugs.python.org/issue44643>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
Patrick Reader added the comment: It may be, but in that case, why do LOAD_BUILD_CLASS and things still use it? -- ___ Python tracker <https://bugs.python.org/issue44643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
Patrick Reader added the comment: Similarly, when passing a subclass of dict to exec or eval as the locals or globals, all other instructions dispatch to the correct __getitem__ method. I'm pretty sure that's not CPython-private -- ___ Python tracker <https://bugs.python.org/issue44643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44643] importing does not dispatch to __builtins__.__getitem__ to lookup __import__
Patrick Reader added the comment: Ok what I meant was, why does constructing a class use it when it looks up __build_class__ then? -- ___ Python tracker <https://bugs.python.org/issue44643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42167] Documentation for SETUP_WITH opcode is wrong
Patrick Reader added the comment: It was, at least partially, replaced by BEGIN_WITH for bpo-40222: https://github.com/python/cpython/commit/adcd2205565f91c6719f4141ab4e1da6d7086126#diff-eaa488fc50d23b30ca8b24ab19e9c91c1c941339847af993e908f006eec0653bL741 -- versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue42167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44845] Allow keyword arguments in code.__new__
New submission from Patrick Reader : Per bpo-41263, code.__new__ now uses Argument Clinic. However, it still has a / marker which prevents the use of keyword arguments (https://github.com/python/cpython/pull/21426/files#diff-6f869eb8beb7cbe4bc6817584b99ad567f88962fa67f7beca25d009dc401234dR465). It seems entirely unnecessary to have this, so could it be removed to allow easier construction of code objects from user code, or is it there for some specific reason? I can do a PR - it's a 1 line change (+ clinic output changes) (+ tests?). I don't imagine backwards-compatibility is a concern here given it's implementation-specific and basically private. Note that prior to that fix, keyword arguments were allowed in the constructor but completely ignored. -- components: Interpreter Core messages: 399034 nosy: pxeger priority: normal severity: normal status: open title: Allow keyword arguments in code.__new__ type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45352] Move documentation for typed generic forms of standard collections to collections.abc
New submission from Patrick Reader : Currently the documentation for the generic forms (e.g. what the parameters in square brackets mean) of standard collections (e.g. collections.abc.Generator), is still on the typing page (https://docs.python.org/3.10/library/typing.html#typing.Generator). This is from before PEP 585 was implemented, which deprecated the ones in typing in favour of the aliases in collections.abc. The documentation for these should be moved, or at least linked to, in the collections.abc page. The same applies to builtin types like list which can now also be directly parameterised. In the case of Generator, for example, the text at https://docs.python.org/3.10/library/typing.html#typing.Generator, "A generator can be annotated...", should be moved to https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Generator. I chose Generator as an example, because it has three parameters YieldType, SendType, ReturnType whose order I can't remember and need to look up. For some types, such as Iterable, the meaning of the parameter is quite straightforward, so little documentation is needed (so https://docs.python.org/3.10/library/typing.html#typing.Iterable just says "A generic form of https://docs.python.org/3.10/library/collections.abc.html#collections.abc.Iterable";), but there should still be a note on the collections.abc page that it can be parameterised. Perhaps there should also be a message saying "new in version 3.9: this can now be parameterised" on each ABC collection. I can see that it might not be desirable to have this information scattered across other pages, because it is fundamentally about typing and pretty unrelated to builtin documentation, so it may be preferable to just link to the typing page rather than move the text. But since the old generics are deprecated, if they are removed, the documentation must be preserved. -- assignee: docs@python components: Documentation messages: 403085 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Move documentation for typed generic forms of standard collections to collections.abc type: enhancement ___ Python tracker <https://bugs.python.org/issue45352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44845] Allow keyword arguments in code.__new__
Change by Patrick Reader : -- nosy: -terry.reedy ___ Python tracker <https://bugs.python.org/issue44845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41781] Typos in typing.py
Patrick Reader added the comment: Maybe I added myself by accident while reading the code. Anyway, thanks and you're welcome -- ___ Python tracker <https://bugs.python.org/issue41781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler
New submission from Patrick Reader :
When unpacking a collection or string literal inside another literal, the
compiler should optimise the unpacking away and store the resultant collection
simply as another constant tuple, so that `[*'123', '4', '5']` is the exact
same as `['1', '2', '3', '4', '5']`.
Compare:
```
>>> dis.dis("[*'123', '4', '5']")
1 0 BUILD_LIST 0
2 BUILD_LIST 0
4 LOAD_CONST 0 ('123')
6 LIST_EXTEND 1
8 LIST_EXTEND 1
10 LOAD_CONST 1 ('4')
12 LIST_APPEND 1
14 LOAD_CONST 2 ('5')
16 LIST_APPEND 1
```
vs.
```
>>> dis.dis("['1', '2', '3', '4', '5']")
1 0 BUILD_LIST 0
2 LOAD_CONST 0 (('1', '2', '3', '4', '5'))
4 LIST_EXTEND 1
```
and `timeit` shows the latter to be over 3 times as fast.
For example, when generating a list of characters, it is easier and more
readable to do `alphabet = [*"abcde"]` instead of `alphabet = ["a", "b", "c",
"d", "e"]`. The programmer can do what is most obvious without worrying about
performance, because the compiler can do it itself.
--
components: Interpreter Core
messages: 383837
nosy: pxeger
priority: normal
severity: normal
status: open
title: Unpacking of literals inside other literals should be optimised away by
the compiler
___
Python tracker
<https://bugs.python.org/issue42754>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42754] Unpacking of literals inside other literals should be optimised away by the compiler
Change by Patrick Reader : -- type: -> performance ___ Python tracker <https://bugs.python.org/issue42754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
New submission from Patrick Reader : Since 10.12 (Sierra, released in 2016), macOS is no longer called OS X. References to macOS in the documentation should be updated to reflect this. This is now especially important because macOS 11 (Big Sur) is now in preview, and the X meaning 10 in roman numerals is now completely incorrect (not just the wrong name). -- assignee: docs@python components: Documentation messages: 372951 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Replace references to OS X in documentation with macOS type: behavior ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
Patrick Reader added the comment: I'm working on it -- ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
Patrick Reader added the comment: While I'm at it, should I change "Macintosh" to "Mac"? -- ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41203] Replace references to OS X in documentation with macOS
Change by Patrick Reader : -- keywords: +patch pull_requests: +20468 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21316 ___ Python tracker <https://bugs.python.org/issue41203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41781] Typos in typing.py
New submission from Patrick Reader : In typing.py, the `_allow_reckless_class_cheks` function is spelt wrong, and there is also a typo `instnance` in its docstring. I can do a PR but I thought I'd open an issue since it might be considered a breaking change (although it is `_private` so maybe not?) https://github.com/python/cpython/blob/1b4552c5e8e925f24c15f707050f22c977171125/Lib/typing.py#L1037 -- components: Library (Lib) messages: 376877 nosy: pxeger priority: normal severity: normal status: open title: Typos in typing.py versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41792] No (public) way to dynamically introspect if an annotation is a TypedDict
New submission from Patrick Reader : See https://github.com/python/typing/issues/751 -- components: Library (Lib) messages: 376931 nosy: pxeger priority: normal severity: normal status: open title: No (public) way to dynamically introspect if an annotation is a TypedDict ___ Python tracker <https://bugs.python.org/issue41792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41792] No (public) way to dynamically introspect if an annotation is a TypedDict
Change by Patrick Reader : -- keywords: +patch pull_requests: +21309 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22254 ___ Python tracker <https://bugs.python.org/issue41792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41805] types.GenericAlias and types.Union have no documentation
New submission from Patrick Reader : See title. For reference: `GenericAlias` was added by Guido van Rossum in commit 48b069a003ba6c684a9ba78493fbbec5e89f10b8 "bpo-39481: Implementation for [PEP 585](https://www.python.org/dev/peps/pep-0585/) (#18239)" `Union` was added by Maggi Moss in commit 1b4552c5e8e925f24c15f707050f22c977171125 "bpo-41428: Implementation for [PEP 604](https://www.python.org/dev/peps/pep-0604/) (GH-21515)" I can do a PR which would need backporting (is that the right word?) to 3.9 at least for `GenericAlias`. -- assignee: docs@python components: Documentation messages: 377064 nosy: docs@python, pxeger priority: normal severity: normal status: open title: types.GenericAlias and types.Union have no documentation versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41805] types.GenericAlias and types.Union have no documentation
Patrick Reader added the comment: Sorry, I'd completely forgotten about doing a PR for this. Go ahead! -- ___ Python tracker <https://bugs.python.org/issue41805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41996] Should `make install` still install to /usr/bin/python3?
New submission from Patrick Reader : Since Python 2 is now finally gone, should the Python executable not be installed to simply `/usr/bin/python` rather than `/usr/bin/python3` when running `make install`? -- components: Installation messages: 378387 nosy: pxeger priority: normal severity: normal status: open title: Should `make install` still install to /usr/bin/python3? type: enhancement ___ Python tracker <https://bugs.python.org/issue41996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41997] Docs Standard Library index page has incorrect version in title
New submission from Patrick Reader : The documentation page for the Standard Library, https://docs.python.org/3/library/, still says "Python 3.8.6 documentation" in the title. When visiting https://docs.python.org/3.9/library/ (emphasis on the 3.9) explicitly, the correct title is shown. I suspect there are other pages like this, perhaps ones that have not been modified since Python 3.8.6? This is possibly in fact some sort of bug in Sphinx, but I don't think so. -- assignee: docs@python components: Documentation messages: 378394 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Docs Standard Library index page has incorrect version in title versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41997] Docs Standard Library index page has incorrect version in title
[issue42167] Documentation for SETUP_WITH opcode is wrong
New submission from Patrick Reader : bpo-33387 introduced two new opcodes, `RERAISE` and `WITH_EXCEPT_START` (previously called `WITH_EXCEPT_FINISH`), replacing the previous `WITH_CLEANUP_START`, `WITH_CLEANUP_FINISH`, `BEGIN_FINALLY`, `END_FINALLY`, `CALL_FINALLY` and `POP_FINALLY`. The [documentation](https://docs.python.org/3.9/library/dis.html#opcode-SETUP_WITH) for it references the since removed `WITH_CLEANUP_START`, which is definitely wrong. I don't know enough to be able to fix it though, sorry, so I've added the core team. -- assignee: docs@python components: Documentation, Interpreter Core messages: 379749 nosy: docs@python, pxeger priority: normal severity: normal status: open title: Documentation for SETUP_WITH opcode is wrong versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
