PEP 3099 – Things that will Not Change in Python 3000 | peps.python.org
Following system colour scheme
Selected dark colour scheme
Selected light colour scheme
Python Enhancement Proposals
Toggle light / dark / auto colour theme
PEP 3099 – Things that will Not Change in Python 3000
PEP 3099 – Things that will Not Change in Python 3000
Author
:
Georg Brandl <georg at python.org>
Status
:
Final
Type
:
Process
Created
:
04-Apr-2006
Post-History
:
Table of Contents
Some ideas are just bad. While some thoughts on Python evolution are
constructive, some go against the basic tenets of Python so
egregiously that it would be like asking someone to run in a circle:
it gets you nowhere, even for Python 3000, where extraordinary
proposals are allowed. This PEP tries to list all BDFL pronouncements
on Python 3000 that refer to changes that will not happen and new
features that will not be introduced, sorted by topics, along with
a short explanation or a reference to the relevant thread on the
python-3000 mailing list.
If you think you should suggest any of the listed ideas it would be
better to just step away from the computer, go outside, and enjoy
yourself. Being active outdoors by napping in a nice patch of grass
is more productive than bringing up a beating-a-dead-horse idea and
having people tell you how dead the idea is. Consider yourself warned.
- Python 3000 will not be case-insensitive.
- Python 3000 will not be a rewrite from scratch.
- self will not become implicit.
- lambda will not be renamed.
At one point lambda was slated for removal in Python 3000.
Unfortunately no one was able to come up with a better way of
providing anonymous functions. And so lambda is here to stay.
But it is here to stay as-is. Adding support for statements is a
non-starter. It would require allowing multi-line lambda
expressions which would mean a multi-line expression could suddenly
exist. That would allow for multi-line arguments to function
calls, for instance. That is just plain ugly.
Thread: “genexp syntax / lambda”,
https://mail.python.org/pipermail/python-3000/2006-April/001042.html
- Python will not have programmable syntax.
- There won’t be a syntax for zip()-style parallel iteration.
- Strings will stay iterable.
- There will be no syntax to sort the result of a generator expression
or list comprehension. sorted() covers all use cases.
- Slices and extended slices won’t go away (even if the __getslice__
and __setslice__ APIs may be replaced) nor will they return views
for the standard object types.
- It will not be forbidden to reuse a loop variable inside the loop’s
suite.
- The parser won’t be more complex than LL(1).
Simple is better than complex. This idea extends to the parser.
Restricting Python’s grammar to an LL(1) parser is a blessing,
not a curse. It puts us in handcuffs that prevent us from going
overboard and ending up with funky grammar rules like some other
dynamic languages that will go unnamed, such as Perl.
- No braces.
This is so obvious that it doesn’t need a reference to a mailing
list. Do from __future__ import braces to get a definitive
answer on this subject.
- No more backticks.
Backticks (`) will no longer be used as shorthand for
repr –
but that doesn’t mean they are available for other uses. Even
ignoring the backwards compatibility confusion, the character
itself causes too many problems (in some fonts, on some keyboards,
when typesetting a book, etc).
Thread: “new operators via backquoting”,
https://mail.python.org/pipermail/python-ideas/2007-January/000054.html
- Referencing the global name foo will not be spelled globals.foo.
The global statement will stay.
- There will be no alternative binding operators such as :=.
- We won’t be removing container literals.
That is, {expr: expr, …}, [expr, …] and (expr, …) will stay.
- The else clause in while and for loops will not change
semantics, or be removed.
- zip() won’t grow keyword arguments or other mechanisms to prevent
it from stopping at the end of the shortest sequence.
- hash() won’t become an attribute since attributes should be cheap
to compute, which isn’t necessarily the case for a hash.
- Iterating over a dictionary will continue to yield the keys.
- There will be no frozenlist type.
- int will not support subscripts yielding a range.
- The (recommended) maximum line width will remain 80 characters,
for both C and Python code.
- The interpreter prompt (>>>) will not change. It gives Guido warm
fuzzy feelings.
This document has been placed in the public domain.
Contents
Page Source (GitHub)
Source: https://github.com/python/peps/blob/main/peps/pep-3099.rst
Last modified: 2025-02-01 08:59:27 UTC