On Wed, Jan 11, 2017 at 9:37 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> I have a proposal for an Informational PEP that lists things which will > > not change in Python. If accepted, it could be linked to from the signup > > page for the mailing list, and be the one obvious place to point > > newcomers to if they propose the same old cliches. > > > > Thoughts? > > > > > > > > > > * * * * * * * * * * > > > > > > PEP: XXX > > Title: Things that won't change in Python > > Version: $Revision$ > > Last-Modified: $Date$ > > Author: Steven D'Aprano <st...@pearwood.info> > > Status: Draft > > Type: Informational > > Content-Type: text/x-rst > > Created: 11-Jan-2017 > > Post-History: 12-Jan-2017 > > > > > > Abstract > > ======== > > > > This PEP documents things which will not change in future versions of > Python. > > > > > > Rationale > > ========= > > > > This PEP hopes to reduce the noise on `Python-Ideas < > https://mail.python.org/mailman/listinfo/python-ideas>`_ > > and other mailing lists. If you have a proposal for future Python > > development, and it requires changing one of the things listed here, it > > is dead in the water and has **no chance of being accepted**, either > because > > the benefit is too little, the cost of changing the language (including > > backwards compatibility) is too high, or simply because it goes against > > the design preferred by the BDFL. > > > > Many of these things are already listed in the `FAQs < > https://docs.python.org/3/faq/design.html>`_. > > You should be familiar with both Python and the FAQs before proposing > > changes to the language. > > > > Just because something is not listed here does not necessarily mean that > > it will be changed. Each proposal will be weighed on its merits, costs > > compared to benefits. Sometimes the decision will come down to a matter > > of subjective taste, in which case the BDFL has the final say. > > > > > > Language Direction > > ================== > > > > Python 3 > > -------- > > > > This shouldn't need saying, but Python 3 will not be abandoned. > > > > > > Python 2.8 > > ---------- > > > > There will be `no official Python 2.8 <https://www.python.org/dev/ > peps/pep-0404/>`_ , > > although third parties are welcome to fork the language, backport Python > > 3 features, and maintain the hybrid themselves. Just don't call it > > "Python 2.8", or any other name which gives the impression that it > > is maintained by the official Python core developers. > > > > > > Type checking > > ------------- > > > > Duck-typing remains a fundamental part of Python and `type checking < > https://www.python.org/dev/peps/pep-0484/#non-goals>`_ > > will not be mandatory. Even if the Python interpreter someday gains a > > built-in type checker, it will remain optional. > > > > > > Syntax > > ====== > > > > Braces > > ------ > > > > It doesn't matter whether optional or mandatory, whether spelled ``{ }`` > > like in C, or ``BEGIN END`` like in Pascal, braces to delimit code blocks > > are not going to happen. > > > > For another perspective on this, try running ``from __future__ import > braces`` > > at the interactive interpreter. > > > > (There is a *tiny* loophole here: multi-statement lambda, or Ruby-like code > > blocks have not been ruled out. Such a feature may require some sort of > > block delimiter -- but it won't be braces, as they clash with the syntax > > for dicts and sets.) > > > > > > Colons after statements that introduce a block > > ---------------------------------------------- > > > > Statements which introduce a code block, such as ``class``, ``def``, or > > ``if``, require a colon. Colons have been found to increase readability. > > See the `FAQ <https://docs.python.org/3/faq/design.html#why-are- > colons-required-for-the-if-while-def-class-statements>`_ > > for more detail. > > > > > > End statements > > -------------- > > > > Python does not use ``END`` statements following blocks. Given significant > > indentation, they are redundant and add noise to the source code. If you > > really want end markers, use a comment ``# end``. > > > > > > Explicit self > > ------------- > > > > Explicit ``self`` is a feature, not a bug. See the > > `FAQ <https://docs.python.org/3/faq/design.html#why-must-self- > be-used-explicitly-in-method-definitions-and-calls>`_ > > for more detail. > > > > > > Print function > > -------------- > > > > The ``print`` statement in Python 1 and 2 was a mistake that Guido long > > regretted. Now that it has been corrected in Python 3, it will not be > > reverted back to a statement. See `PEP 3105 <https://www.python.org/dev/ > peps/pep-3105/>`_ > > for more details. > > > > > > Significant indentation > > ----------------------- > > > > `Significant indentation <https://docs.python.org/3/ > faq/design.html#why-does-python-use-indentation-for-grouping-of-statements > >`_ > > is a core feature of Python. > > > > > > Other syntax > > ------------ > > > > Python will not use ``$`` as syntax. Guido doesn't like it. (But it > > is okay to use ``$`` in DSLs like template strings and regular > > expressions.) > > > > > > Built-in Functions And Types > > ============================ > > > > Strings > > ------- > > > > Strings are `immutable <https://docs.python.org/3/faq/design.html#why-are- > python-strings-immutable>`_ > > and represent Unicode code points, not bytes. > > > > > > Bools > > ----- > > > > ``bool`` is a subclass of ``int``, with ``True == 1`` and ``False == 0``. > > This is mostly for historical reasons, but the benefit of changing it now > > is too low to be worth breaking backwards compatibility and the enormous > > disruption it would cause. > > > > > > Built-in functions > > ------------------ > > > > Python is an object-oriented language, but it is not *purely* > > object-oriented. Not everything needs to be `a method of some object < > http://steve-yegge.blogspot.com.au/2006/03/execution-in- > kingdom-of-nouns.html>`_, > > and functions have their advantages. See the > > `FAQ <https://docs.python.org/3/faq/design.html#why-does- > python-use-methods-for-some-functionality-e-g-list-index- > but-functions-for-other-e-g-len-list>`_ > > for more detail. > > > > > > Other Language Features > > ======================= > > > > The interactive interpreter > > --------------------------- > > > > The default prompt is ``>>> ``. Guido likes it that way. > > > > > > Copyright > > ========= > > > > This document has been placed in the public domain. > > > > > > > > .. > > Local Variables: > > mode: indented-text > > indent-tabs-mode: nil > > sentence-end-double-space: t > > fill-column: 70 > > coding: utf-8 > > End: > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > I like the idea a lot. Some suggested changes: 1. In the introduction, I might add a sentence saying that flags or some other options to change these behaviors will also not be added. 2. I might combine the "braces" and "end statements" into a single section, perhaps "code blocks". At the very least I would have them adjacent to each other in the list. 3. I would add in the "explicit self" section that "self" will also not be made a keyword. 4. I think either adding a bit more detail about the rationale for the decisions, or perhaps better yet having an entry in the FAQ explaining the rationale for each of these decisions that is linked from here, would help avoid arguments (or maybe it could encourage arguments about the rationale, this is debatable). 5. I would add some examples for the "built-in functions" part, such as "length" and "del". 6. I don't think the "Strings" part makes sense to those not already familiar with unicode. I think a couple more sentences explaining the difference, and mentioning that the python 2 behavior is what won't be used, is necessary so such people understand what they should avoid suggesting. 7. I am not sure what "Python will not use ``$`` as syntax." means. Are you referring to a particular common use of "$", or that it won't be used at all for any reason? If the latter, I would add "?" to that as well. 8. In the "python 3" section, perhaps mention that "python 4" will be a continuation of python 3 and will be a major backwards-compatibility break like python 2 -> 3 was. Some sections I would suggest adding 1. A section about indexing, and include that the built-in "range" follows the indexing rules. You can mention that custom classes can use whatever indexing rules they want but breaking the python convention will make it very, very hard for others to use the class. You can also mention that users can also make a custom range function that follows whatever rules they like. 2. Assignment will never be allowed inside expressions. 3. From what I understand, Guido doesn't want a "range" literal. 4. Things like "range", "map", "dict.keys", "dict.values", and "dict.items" will never go back to the Python 2 behavior of returning lists. Also clarify that the python 3 versions do not return iterators, they return instances of special-purpose, read-only classes (views in the case of the "dict" methods). 5. "and" and "or" are short-circuiting operations that return one of the two values given. They will never be non-short-circuiting and they will never coerce returned values to boolean. 6. "xor" will not be added. 7. "if" will not be added to the ordinary "for" statement. 8. Options to change the behavior of built-in classes in incompatible ways will not be added (I may be wrong about this one, but I think it is a good rule).
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
