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
It's finally time to schedule the last releases in Python 2's life. There will be two more releases of Python 2.7: Python 2.7.17 and Python 2.7.18.
Python 2.7.17 release candidate 1 will happen on October 5th followed by the final release on October 19th.
I'm going to time Python 2.7.18 to coincide with PyCon 2020 in April, so attendees can enjoy some collective catharsis. We'll still say January 1st is the official EOL date.
Thanks to Sumana Harihareswara, there's now a FAQ about the Python 2 sunset on the website: https://www.python.org/doc/sunset-python-2/
I think that PEP 573 is ready to be accepted, to greatly improve the state
of extension modules in CPython 3.9.
It has come a long way since the original proposal and went through several
iterations and discussions by various interested people, effectively
reducing its scope quite a bit. So this is the last call for comments on
the latest version of the PEP, before I will pronounce on it. Please keep
the discussion in this thread.
An unfortunate side-effect of making PyInterpreterState in Python 3.8 opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) support. https://www.python.org/dev/peps/pep-0523/ was opened to try and fix this, but there seems to be a stalemate in the issue.
A key question is at what API level should setting the frame evaluation function live at? No one is suggesting the stable ABI, but there isn't agreement between CPython or the internal API (there's also seems to be a suggestion to potentially remove PEP 523 support entirely).
And regardless of either, there also seems to be a disagreement about providing getters and setters to continue to try and hide PyInterpreterState regardless of which API level support is provided at (if any).
If you have an opinion please weight in on the issue.
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
What do people think of the idea of requiring all deprecations specifying a version that the feature will be removed in (which under our annual release cadence would be at least the third release from the start of the deprecation, hence the deprecation being public for 2 years)? And that we also follow through with that removal?
Now I'm not suggesting it **must** be in three feature releases. A deprecation could be set to Python 4 if people truly feel keeping the code is as easy it gets in terms of maintenance and there's enough usage to warrant such a potential indefinite deprecation/maintenance while keeping the code and docs alive (basically "there are better ways to do this, but this works fine, too, if you were already using it"). But what I am trying to avoid is the semi-regular discussion we seem to have of what is or is not reasonable to deprecate and leave versus deprecate and eventually remove because we didn't specify what the eventual plan was for a deprecation. Also feel like it would help users to know specifically what the plan is with a deprecation rather than wondering if something will get removed in the next feature release or not because we left off a specific removal version.
If people are amenable to this idea I will update PEP 387 (which I plan to start a discussion about post-SC election) and I would also plan to add a warnings._deprecate() which I roughly outlined once at https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/103….
Today I discovered the this struct
const char* name;
unsigned int flags;
PyType_Slot *slots; /* terminated by slot==0. */
with "PyTypeSlot *slots" being on line 190 of object.h causes a problem when compiled with code that brings in Qt. Qt has macro definitions of slots.
With a cursory preprocessing of the file I was working with, using the handy gcc options -dM -E, I found that
slots was defined to nothing
and hence caused problems when object.h was brought into the mix.
I will try to make a simple reproducer tomorrow. I know this probably could be solved by header file inclusion re-ordering,
or in some cases #undef'ing slots before including Python.h, but I also thought the Python dev team would like to know
about this issue.