[issue46520] `ast.unparse` produces syntactically illegal code for identifiers that look like reserved words
New submission from Kodiologist :
This works:
𝕕𝕖𝕗 = 1
This raises SyntaxError:
import ast
exec(ast.unparse(ast.parse("𝕕𝕖𝕗 = 1")))
It looks like `ast.parse` creates a `Name` node with `id='def'`, which is
correct per PEP 3131, but `ast.unparse` doesn't know it needs to mangle the
output somehow, as "𝕕𝕖𝕗" or a similar Unicode replacement.
--
components: Library (Lib)
messages: 411606
nosy: Kodiologist
priority: normal
severity: normal
status: open
title: `ast.unparse` produces syntactically illegal code for identifiers that
look like reserved words
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46520>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46520] `ast.unparse` produces syntactically illegal code for identifiers that look like reserved words
Kodiologist added the comment: I've done very little work on CPython, but I do a lot of AST construction and call `ast.unparse` a lot in my work on Hylang, and I think this is a wart worth fixing. The real mistake was letting the user say `𝕕𝕖𝕗 = 1`, but that's been legal Python syntax for a long time, so I doubt a change to that would be welcome, especially one affecting old stable versions of Python like 3.9. Python has made its bed and now it must lie in it. I think that with a pretty small amount of code (using code-point arithmetic instead of a dictionary with every ASCII letter), I can add Unicode "escaping" of reserved words to the part of `ast.unparse` that renders variable names. Would a patch of this kind be welcome? -- ___ Python tracker <https://bugs.python.org/issue46520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46520] `ast.unparse` produces syntactically illegal code for identifiers that look like reserved words
Kodiologist added the comment: And yes, while this behavior will look strange, the only code that will parse to AST nodes that require it will be code that uses exactly the same trick. -- ___ Python tracker <https://bugs.python.org/issue46520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46555] Unicode-mangled names refer inconsistently to constants
New submission from Kodiologist : I'm not sure if this is a bug, but it certainly surprised me. Most reserved words, when Unicode-mangled, as in "𝕕𝕖𝕗", act like ordinary identifiers (see e.g. bpo-46520). `True`, `False`, and `None` are weird in that Unicode-mangled versions of them refer to those same constants initially, but can take on their own identity as variables if assigned to: Python 3.9.7 (default, Sep 10 2021, 14:59:43) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 𝕋𝕣𝕦𝕖 True >>> True = 0 File "", line 1 True = 0 ^ SyntaxError: cannot assign to True >>> 𝕋𝕣𝕦𝕖 = 0 >>> True True >>> 𝕋𝕣𝕦𝕖 0 I think that `𝕋𝕣𝕦𝕖 = 1` should probably be forbidden. The fact that `𝕋𝕣𝕦𝕖` doesn't always mean the same thing as `True` seems to break the rule in PEP 3131 that "comparison of identifiers is based on NFKC". -- messages: 411930 nosy: Kodiologist priority: normal severity: normal status: open title: Unicode-mangled names refer inconsistently to constants type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46520] ast.unparse produces bad code for identifiers that become keywords
Kodiologist added the comment:
(Hilariously, I couldn't post this comment on bugs.python.org due to some kind
of Unicode bug ("Edit Error: 'utf8' codec can't decode bytes in position
208-210: invalid continuation byte"), so I've rendered
"\U0001D555\U0001D556\U0001D557" as "DEF" in the below.)
Thanks for clarifying the terminology re: reserved words vs. keywords.
> The effect is the same as "globals()['DEF']=1" (which is the same as
> passing 'def' or anything else that normalizes to it) and that in
> turn allows ">>> DEF", which returns 1.
This doesn't quite seem to be the case, at least on Pythons 3.9 and 3.10:
>>> globals()['DEF']=1
>>> DEF
Traceback (most recent call last):
File "", line 1, in
NameError: name 'def' is not defined
>>> globals()['def']=1
>>> DEF
1
It looks the dictionary interface to `globals` doesn't normalize like the
parser does.
--
___
Python tracker
<https://bugs.python.org/issue46520>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46520] ast.unparse produces bad code for identifiers that become keywords
Change by Kodiologist : -- keywords: +patch pull_requests: +29191 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31012 ___ Python tracker <https://bugs.python.org/issue46520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46555] Unicode-mangled names refer inconsistently to constants
Kodiologist added the comment: > the builtin variable "True" Is the existence of this entity, as separate from the constant `True`, documented anywhere? constants.rst doesn't seem to acknowledge it. Indeed, is its existence a feature, or is it a CPython quirk? -- ___ Python tracker <https://bugs.python.org/issue46555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16958] The sqlite3 context manager does not work with isolation_level=None
Kodiologist added the comment: This bit me real bad. On Python 3.8, I wrote a program with `isolation_level = None` and `with db: …` and spent a long time figuring out why writes were so slow. Turns out that `with db` doesn't actually start a transaction in this case, as the documentation suggests it should. This issue is approaching the age of 10, so if there's still uncertainty about how the implementation or the interface should change, the docs should be clarified in the meantime. I always thought the Python library turning off autocommit by default, contrary to SQLite's command-line interface, was needlessly surprising. I think it contributed to this problem because the docs about context managers seem to assume you have autocommit off. ------ nosy: +Kodiologist ___ Python tracker <https://bugs.python.org/issue16958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43521] Allow `ast.unparse` to handle NaNs and empty sets
New submission from Kodiologist : `ast.unparse` throws an error on an empty set, and it produces `nan` for NaN, which isn't a legal Python literal. PR to follow shortly. -- messages: 388872 nosy: Kodiologist priority: normal severity: normal status: open title: Allow `ast.unparse` to handle NaNs and empty sets type: enhancement versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43521] Allow `ast.unparse` to handle NaNs and empty sets
Change by Kodiologist : -- keywords: +patch pull_requests: +23662 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24897 ___ Python tracker <https://bugs.python.org/issue43521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40830] Certain uses of dictionary unpacking raise TypeError
New submission from Kodiologist :
On Python 3.8.2, the below program runs without errors. On Python 3.9.0b1, it
raises "TypeError: 'tuple' object is not callable" for the last line.
d1 = {'a': 1}
d2 = {'c': 3}
def fun(a, b, c):
return a, b, c
print(fun(**d1, b='b', **d2))
--
messages: 370400
nosy: Kodiologist
priority: normal
severity: normal
status: open
title: Certain uses of dictionary unpacking raise TypeError
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue40830>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29088] Inconsistent use of underscore in names that start with "is"
New submission from Kodiologist: Compare ``isinstance``, ``issubclass``, and ``islower`` to ``is_integer``, ``is_fifo``, and ``is_enabled``. In Python 3.6, of all the names in the standard library starting with ``is``, I count 69 names with the underscore and 91 without. It seems better to pick one way or the other and stick with it. I would recommend using the underscore, for legibility. -- messages: 284133 nosy: Kodiologist priority: normal severity: normal status: open title: Inconsistent use of underscore in names that start with "is" versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue29088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
