[Python-ideas] Things that won't change (proposed PEP)

[Steven D'Aprano]

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 <steve at 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: