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/
