PEP 3099– Things that will not change in Python 3

Introduction: Python 3.8 has been released, introducing a number of changes. Some of the changes expected to be introduced in 3.9 have also been disclosed. We’ve also looked at topics like GIL removal plans and Guido’s new parser under development, which means Python is alive and well.

Python 3 was bold and radical, shedding much of the old baggage of its predecessor, but at the same time it was relatively restrained (as it always was), and many of the proposals put forward by the community were rejected. While my recent post on 27 Problems with Python design and History mentioned some of the design issues that have settled down, today’s translation focuses on 24 design issues that were explicitly rejected by the authorities.

Most of the questions are minor (case, parentheses, backquotes, line width, etc.), but they can be fun to dig into, so leave a comment.

The original PEP: www.python.org/dev/peps/pe…

PEP title: Things that Will Not Change in Python 3000

PEP作者： Georg Brandl

Created on: 2006-04-04

The cat under the Pea flower

Translation project: github.com/chinesehuaz…

directory

  • The profile
  • Language core
  • Built-in objects
  • The standard type
  • Coding style
  • Interactive interpreter
  • copyright

The profile

Some ideas are bad. While some of the ideas about Python’s evolution are constructive, many of them run counter to Python’s basic tenets, like running in circles: you’re not going anywhere, and even though Python 3000 allows you to make special suggestions, they don’t work.

This PEP attempts to list all BDFL decisions on Python 3000, those that will not change, and new features that will not be introduced, sorted by subject, with a short description or a clue to the Python-3000 mailing list.

If you think you should implement any of the suggestions listed below, you’d better get off the computer, get out of the house, and have fun. Going outdoors and taking a nap on the grass is more constructive than coming up with the idea of beating up a dead horse. This is a warning to you (don’t try to change the decisions you’ve already made).

Language core

  • Python 3000 is not case sensitive.

  • Python 3000 will not be rewritten from scratch.

You will not use C++ or any other language other than C as an implementation language. However, the code base will migrate over time. Joel Spolsky has an excellent article explains why: www.joelonsoftware.com/articles/fo…

  • Self doesn’t become implicit.

Using explicit self is a good thing. Unambiguities when parsing variables can make your code clearer. It also makes the difference between functions and methods smaller.

E-mail: “the draft proposal: Python 3.0 using implicit self” mail.python.org/pipermail/p…

  • Lambda will not be renamed.

There was a proposal to remove lambda from Python 3000. However, no one has come up with a better way to provide anonymous functions. So lambda stays.

But just to keep it the same. Adding its support for statements is not a good idea. Because it needs to allow multi-line lambda expressions, this means that multi-line expressions can pop up and, for example, will allow multi-line arguments to function calls. That’s ugly.

Mail: “genexp grammar/lambda,” mail.python.org/pipermail/p…

  • Python does not add programmable syntax.

Email: “It’s a statement! It’s a function! Both!” Mail.python.org/pipermail/p…

  • There will be no parallel iteration syntax like zip().

Email: “parallel iteration syntax”, mail.python.org/pipermail/p…

  • The string will remain iterable.

Mail: “make the string is iteration”, mail.python.org/pipermail/p…

  • There is no syntax for sorting the results of generator expressions or list comprehensions. Sorted () will cover all usage cases.

Email: “for generator expressions add sorting”, mail.python.org/pipermail/p…

  • Slicing and extended slicing are not cancelled (even though the __getslice__ and __setslice__ apis may be replaced), nor do they return views of standard object types.

Email: the future of slice mail.python.org/pipermail/p…

  • Reuse of loop variables within loop structures is not prohibited.

Mail: eliminate iteration variable scope hemorrhage (scope bleeding) mail.python.org/pipermail/p…

  • The parser is no more complex than LL(1).

Simple is better than complex. This idea applies to parsers. Limiting Python’s syntax to LL(1) parsers is a benefit, not a curse. It keeps us in handcuffs from overreaching and ending up with funky syntax rules like some dynamic language that has gone nowhere, like Perl.

  • There will be no parentheses.

This is too obvious to reference the mailing list. Use from __future__ import braces, and you can get a clear answer to this question.

  • No more backquotes.

Backquotes (‘) will no longer be used as shorthand for repr — but that doesn’t mean they can be used for anything else. Even ignoring the confusion of backward compatibility, the character itself can cause too many problems (in some fonts, on some keyboards, when typesetting books, and so on).

Mail: “use the quotation marks as a new operator,” mail.python.org/pipermail/p…

  • Reference to the global variable name foo will not be spelled globals.foo. The global statement is retained

Email: “replace with global built-in object globals () and global statement”, mail.python.org/pipermail/p… , “Explicit lexical scope (pre-PEP?) “Mail.python.org/pipermail/p…

  • There will be no alternative binding operator, such as :=.

Email: “Explicit lexical scope (pre-PEP?) “Mail.python.org/pipermail/p…

  • We do not delete container literals. {expr:expr,… }, expr… And (expr,…). Will be retained.

Email: “remove containers literal”, mail.python.org/pipermail/p… :

  • Else clauses in while and for loops do not change semantics and are not deleted.

Email: “for/except/else syntax” mail.python.org/pipermail/p…

Built-in objects

  • Zip () does not add keyword arguments or other mechanisms to prevent it from stopping at the end of the shortest sequence.

E-mail: “to the sequence of different length, zip () throw exceptions”, mail.python.org/pipermail/p…

  • Hash () does not become an attribute, because attributes are supposed to be easy to compute, but that is not necessarily the case with hashes.

Email: “hash as attributes/characteristics”, mail.python.org/pipermail/p…

The standard type

  • Traversing the dictionary will continue to return keys.

Email: “traverse dictionary”, mail.python.org/pipermail/p…

E-mail: let the iter (mapping) generated (key, value) of mail.python.org/pipermail/p…

  • There will be nofrozenlistType.

Email: “immutable list”, mail.python.org/pipermail/p…

  • Int does not support subscripts to generate ranges.

Mail: “xrange vs. Int. __ getslice__” mail.python.org/pipermail/p…

Coding style

  • For C and Python code, the (recommended) maximum line width will remain 80 characters.

Email: “C style guide”, mail.python.org/pipermail/p…

Interactive interpreter

  • The interpreter prompt (>>>) does not change. It gives Guido a warm fuzzy feeling.

Email: “Low-hanging fruit: Tips for changing the interpreter?” , mail.python.org/pipermail/p…

copyright

This document is in the public domain. Source: github.com/python/peps…

.

The “mail” appeared in the text is “thread”, English interpretation should be: A series of connected messages on a message board on the Internet which have been sent by different people. “Mailing list” is an item on the mailing list.

The public account “Python Cat”, this serial quality articles, cat philosophy series, Python advanced series, good books recommended series, technical writing, quality English recommended and translation, etc., welcome to pay attention to oh.