In Python 2.5 `0or` was accepted by the Python parser. It became an
error in 2.6 because "0o" became recognizing as an incomplete octal
number. `1or` still is accepted.
On other hand, `1if 2else 3` is accepted despites the fact that "2e" can
be recognized as an incomplete floating point number. In this case the
tokenizer pushes "e" back and returns "2".
Shouldn't it do the same with "0o"? It is possible to make `0or` be
parseable again. Python implementation is able to tokenize this example:
$ echo '0or' | ./python -m tokenize
1,0-1,1: NUMBER '0'
1,1-1,3: NAME 'or'
1,3-1,4: OP '['
1,4-1,5: OP ']'
1,5-1,6: NEWLINE '\n'
2,0-2,0: ENDMARKER ''
On other hand, all these examples look weird. There is an assymmetry:
`1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize
visually the boundary between a number and the following identifier or
keyword, especially if numbers can contain letters ("b", "e", "j", "o",
"x") and underscores, and identifiers can contain digits. On both sides
of the boundary can be letters, digits, and underscores.
I propose to change the Python syntax by adding a requirement that there
should be a whitespace or delimiter between a numeric literal and the
I'd like to discuss the idea to add a module to parse TOML [toml-lang]
to Python's standard library.
PEP-0518 -- Specifying Minimum Build System Requirements for Python
Projects [pep] suggests to store build system dependencies in
`pyproject.toml`, yet Python itself does not support this format.
Various packaging related projects like pip and pipenv already support
PEP-0518 and vendored one of the existing TOML libraries in order to
read `pyproject.toml` files.
Besides that, TOML seems a better alternative to .cfg/.ini, .json --
both of which are already supported by Python's standard lib and
parsing/dumping TOML properly is tricky enough to solve it properly
There are a couple of TOML implementations out there [toml, pytoml,
tomlkit] and one would have to find out which one to prefer and migrate
into the stdlib.
If the result of this discussion is leaning towards adding TOML, I'd
volunteer to do it. This includes: coordinating with the maintainer of
the chosen library, writing the PEP (hopefully with some help) and
maintain the module for at least two years.
Dr. Bastian Venthur http://venthur.de
Debian Developer venthur at debian org
webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place. Is there some guide I should be
sending them to, 'how to debug installation problems'?
The installer dialog mentions Python will be installed in something like
$USERPROFILE\AppData\Local\Programs\Python\Python37-32 while at the same
time suggesting it will be made available for all users through the
"Install launcher for all users (recommended)". This is confusing -- if the
package is to be made available for everybody, it shouldn't be installed
somewhere under the profile folder of whomever is installing it, normally
other people can't even access this folder at all.
It should be installed in %Program Files(x86)%, unless it is a private
installation indeed (the "Install launcher for all users" is unchecked).
Is this an omission of sorts? Is one expected to correct this themselves,
during installation -- I don't see where one would even specify the
(cross posting to python-committers, python-dev, core-workflow)
PEP 581: Using GitHub Issues has been accepted by the steering council, but
PEP 588: GitHub Issues Migration plan is still in progress.
I'd like to hear from core developers as well as heavy b.p.o users, the
1. what features do they find lacking from GitHub issues, or
2. what are the things you can do in b.p.o but not in GitHub, or
3. Other workflow that will be blocked if we were to switch to GitHub
By understanding your needs, we can be better prepared for the migration,
and we can start looking for solutions.
In addition, I received tip that the GitHub team is very motivated to help
us, and if we can give them some of our most wanted features, they *might* be
able to accommodate us. But first we need to tell them what we need.
They're not promising anything, but I'd like to at least try and give them
1. Please leave your comment in this issue:
2. Leave your +1 by reacting 👍 to suggested feature by others
3. Please do this before October 1, 2019 (not a hard deadline)
It's time for the last beta release of Python 3.8. Go find it at:
This release is the last of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. The next pre-release of Python 3.8 will be 3.8.0c1, the first release candidate, currently scheduled for 2019-09-30.
Call to action
We strongly encourage maintainers of third-party Python projects to test with 3.8 during the beta phase and report issues found to the Python bug tracker as soon as possible. Please note this is the last beta release, there is not much time left to identify and fix issues before the release of 3.8.0. If you were hesitating trying it out before, now is the time.
While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and no code changes after 3.8.0c1, the release candidate.
To achieve that, it will be extremely important to get as much exposure for 3.8 as possible during the beta phase. That beta phase is coming to an end. Please test now.
Please keep in mind that this is a preview release and its use is not recommended for production environments.
Many developers worked hard for the past four weeks to squash remaining bugs, some requiring non-obvious decisions. Many thanks to the most active, namely Raymond Hettinger, Steve Dower, Victor Stinner, Terry Jan Reedy, Serhiy Storchaka, Pablo Galindo Salgado, Tal Einat, Zackery Spytz, Ronald Oussoren, Neil Schemenauer, Inada Naoki, Christian Heimes, and Andrew Svetlov.
3.8.0 would not reach the Last Beta without you. Thank you!
Thanks for doing this. I hope it encourages more participation.
The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue.
ISTM the primary value of having triager is to tag issues appropriately, summon the appropriate experts, and make a first pass at review and/or improvements.
FWIW, the definition of the word triage is "in medical use: the assignment of degrees of urgency to wounds or illnesses to decide the order of treatment of a large number of patients or casualties." That doesn't imply making a final disposition.
Put another way, the only remaining distinction between a "triager" and a "core developer" is the ability to push the "commit" button. In a way, that is the least interesting part of the process and is often a foregone conclusion by the time it happens.