Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.
The PSF is happy to announce that the new Python release will be
Why the version 8? It's just to be greater than Perl 6 and PHP 7, but
it's also a mnemonic for PEP 8. By the way, each minor release will now
multiply the version by 2. With Python 8 released in 2016 and one
release every two years, we will beat Firefox 44 in 2022 (Python 64) and
Windows 2003 in 2032 (Python 2048).
A major release requires a major change to justify a version bump: the
new killer feature is that it's no longer possible to import a module
which does not respect the PEP 8. It ensures that all your code is pure.
$ python8 -c 'import keyword'
Lib/keyword.py:16:1: E122 continuation line missing indentation or outdented
Lib/keyword.py:16:1: E265 block comment should start with '# '
Lib/keyword.py:50:1: E122 continuation line missing indentation or outdented
ImportError: no pep8, no glory
Good news: since *no* module of the current standard library of Python 3
respect the PEP 8, the standard library will be simplified to one
unique module, which is new in Python 8: pep8. The standard library will
move to the Python Cheeseshop (PyPI), to reply to an old and popular
DON'T PANIC! You are still able to import your legacy code into
Python 8, you just have to rename all your modules to add a "_noqa" suffix
to the filename. For example, rename utils.py to utils_noqa.py. A side
effect is that you have to update all imports. For example, replace
"import django" with "import django_noqa". After a study of the PSF,
it's a best option to split again the Python community and make sure
that all users are angry.
The plan is that in 10 years, at least 50% of the 77,000 packages on the
Python cheeseshop will be updated to get the "_noqa" tag. After 2020,
the PSF will start to sponsor trolls to harass users of the legacy
Python 3 to force them to migrate to Python 8.
Python 8 is a work-in-progress (it's still an alpha version), the
standard library was not removed yet. Hopefully, trying to import any
module of the standard library fails.
Don't hesitate to propose more ideas to make Python 8 more incompatible
with Python 3!
Note: The change is already effective in the default branch of Python:
On Fri, Apr 1, 2016 at 8:44 AM, Victor Stinner <victor.stinner(a)gmail.com> wrote:
> You should now try Python 8 and try find if a module can still be imported ;-)
Okay.... I can fire up interactive Python and 'import this'. But I
can't run 'make'. This will be interesting!
I'm not sure if this is the right place to ask, but seeing I was fairly
active here when developing scandir and getting it into Python 3.5, so I
thought I'd start here.
I'm the author and current maintainer of the scandir
<https://pypi.python.org/pypi/scandir> module (Python 3.5's os.scandir but
for Python 2.x and 3.x before 3.5). But I've taken on a few new
non-programming projects and found I don't have time for the little
improvements and fixes that are now in CPython's os.scandir and should be
backported into the PyPI module.
So I'm looking for someone who wants to take over the maintenance of the
scandir PyPI module. It wouldn't be much work, as there are only a couple
of fairly small issues to fix. Or it might be a good way to start for
someone who wants to contribute to a small but useful open source module in
the Python ecosystem.
Any takers, or suggestions for where I could look further for a maintainer?
I am extremely interested in working for the Roundup issue tracker's github
integration part.I am proficient in python and git and have worked before
also on the git.
It is requested to review the proposal for the same.
Thank you for the consideration.A quick reply is appreciated.
On Sun Mar 20 16:26:03 EDT 2016, Nikolaus Rath wrote:
> Which I believe makes it completely pointless to cite Python at all. As
> far as I can see, nowadays citations are given for two reasons:
> 1. To give the reader a starting point to get more information on a
I don't often see references to good "starting points", but I'll grant
the "get more information".
> 2. To formally acknowledge the work done by someone else (who ends up
> with an increased number of citations for the cited publication,
> which is unfortunately a crucial metric in most academic hiring and
> evaluation processes).
There is a third category, of reader service.
When I as a reader have wanted to follow a citation, it was because I
wanted to know more about the specific claim it supposedly supported.
In a few cases -- and these were probably the cases most valuable to
the authors -- I wanted to build on the work, or test it out under
new conditions. Ideally, my first step was to replicate the original
result, to ensure that anything new I found was really caused by the
intentional changes. If I was looking at a computational model, I
really didn't even have the excuse of "too expensive to run that
For papers more than a few years old, even if the code was available,
it generally didn't run -- and often didn't even compile. Were there
a few missing utility files, or had they been using a language variant
different from what had eventually become the standard?
Obviously, it would have been better to just get a copy of the
original environment, PDP and all. In real life, it was very
helpful to know which version of which compiler the authors had
been using. Even the authors who had managed to save their code
didn't generally remember that level of detail about the original
Python today has much better backwards compatibility, but ...
if some junior grad student (maybe not in CS) today came across code
raising strings instead of Exceptions, how confident would she be that
she had the real code, as opposed to a mangled transcription? Would it
help if the paper had a citation that specified CPython 2.1 and she
could still download a version of that ... where it worked?
If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them. -jJ
On 21.03.16 23:01, victor.stinner wrote:
> changeset: 100640:aca4e9af1ca6
> user: Victor Stinner <victor.stinner(a)gmail.com>
> date: Mon Mar 21 22:00:58 2016 +0100
> hashtable.h now supports keys of any size
> Issue #26588: hashtable.h now supports keys of any size, not only
> sizeof(void*). It allows to support key larger than sizeof(void*), but also to
> use less memory for key smaller than sizeof(void*).
If key size is compile time constant, Py_MEMCPY() and memcpy() can be
optimized in one machine instruction. If it is ht->key_size, it adds
more overhead. These changes can have negative performance effect.
It can be eliminated if pass a compile time constant to
I'm seeing that our code increases the reference counting to Py_None,
and I find this a little strange: isn't Py_None eternal and will never
What's the point of counting its references?
Here's another proposal for a change to PEP 484.
In https://github.com/python/typing/issues/72 there's a long
discussion ending with a reasonable argument to allow @overload in
(non-stub) modules after all.
This proposal does *not* sneak in a syntax for multi-dispatch -- the
@overload versions are only for the benefit of type checkers while a
single non-@overload implementation must follow that handles all
cases. In fact, I expect that if we ever end up adding multi-dispatch
to the language or library, it will neither replace not compete with
@overload, but the two will most likely be orthogonal to each other,
with @overload aiming at a type checker and some other multi-dispatch
aiming at the interpreter. (The needs of the two cases are just too
different -- e.g. it's hard to imagine multi-dispatch in Python use
type variables.) More details in the issue (that's also where I'd like
to get feedback if possible).
I want to settle this before 3.5.2 goes out, because it requires a
change to typing.py in the stdlib. Fortunately the change will be
backward compatible (even though this isn't strictly required for a
provisional module). In the original typing module, any use of
@overload outside a stub is an error (it raises as soon as it's used).
In the new proposal, you can decorate a function with @overload, but
any attempt to call such a decorated function raises an error. This
should catch cases early where you forget to provide an
(Reference for provisional modules: https://www.python.org/dev/peps/pep-0411/)
--Guido van Rossum (python.org/~guido)
PEP 484 was already updated to support signatures as type comments in
Python 2.7. I'd like to add two more variations to this spec, both of
which have already come up through users.
First, https://github.com/python/typing/issues/188. This augments the
format of signature type comments to allow (...) instead of an
argument list. This is useful to avoid having to write (Any, Any, Any,
..., Any) for a long argument list if you don't care about the
argument types but do want to specify the return type. It's already
implemented by mypy (and presumably by PyCharm). Example:
def gcd(a, b):
# type: (...) -> int
Second, https://github.com/python/typing/issues/186. This builds on
the previous syntax but deals with the other annoyance of long
argument lists, this time in case you *do* care about the types. The
proposal is to allow writing the arguments one per line with a type
comment on each line. This has been implemented in PyCharm but not yet
in mypy. Example:
a, # type: int
b, # type: int
# type: (...) -> int
In both cases we've considered a few alternatives and ended up
agreeing on the best course forward. If you have questions or feedback
on either proposal it's probably best to just add a comment to the
GitHub tracker issues.
A clarification of the status of PEP 484: it was provisionally
accepted in May 2015. Having spent close to a year pondering it, and
the last several months actively using it at Dropbox, I'm now ready to
move with some improvements based on these experiences (and those of
others who have started to use it). We already added the basic Python
2.7 compatible syntax (see thread starting at
and having used that for a few months the two proposals mentioned
above handle a few corner cases that were possible but a bit awkward
in our experience.
--Guido van Rossum (python.org/~guido)