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

[Sven R. Kunze]

Good evening to everybody,

On 12.01.2017 03:37, Steven D'Aprano 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?


Let me first express my general thoughts on this topic.

First of all, I am anti-censor and pro-change.

So you can imagine that I am not overly excited to see such a document 
form for Python in general. If it's just to prevent spam on this mailing 
list and to reduce the signal/noise ratio here, I tend to agree with you 
if this document were to be attached to this mailing list only.

I don't think Python as the umbrella term for a language, an ecosystem, 
etc. will benefit from preventing change and from banning thoughts no 
matter how strange they may seem first and to some people.


Alright, after that's sorted out, I took my time to go through the list 
below in case the document will be accepted or made official in any form.
So, please find my comment inserted there and some general thoughts at 
the very end.

>
> PEP: XXX
>
> Title: Things that won't change in Python

This a very absolute-sounding title. Maybe inserting a "(most likely)" 
between "that" and "won't" will give it the right nudge.

>
> 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.

Same "(most likely)" here.

>
>
>
>
>
> 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.
>

I like these paragraphs.

>
>
>
> Language Direction
>
> ==================
>
>
>
> Python 3
>
> --------
>
>
>
> This shouldn't need saying, but Python 3 will not be abandoned.
>
>

Don't think this section is necessary. It's more like a project 
management decision not a real change.

>
>
> 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.
>

Same here.

> Type checking
>
> -------------
> [...]

Okay.

> Syntax
>
> ======
>
>
>
> Braces
>
> ------
>
> [...]

Okay but a bit long. Especially the loophole description plays against 
the intention of the document; which is natural because we talk about 
change here. So, nobody knows; and neither do the authors of this 
document. Not saying, the loophole description should be removed. It's a 
perfect summary of the current situation but shifts the focus of the 
document and dilutes its core message.

> Colons after statements that introduce a block
>
> ----------------------------------------------
>
>
>
> [...]

Okay.

> End statements
>
> --------------
>
> [...]

Okay.

> Explicit self
>
> -------------
>
> [...]

Okay.

> Print function
>
> --------------
>
> [...]

Works for me, although the newbies I know of definitely disagree here. ;-)

> Significant indentation
>
> -----------------------
>
> [...]

Okay.

> Other syntax
>
> ------------
>
> [...]

Okay.

> Built-in Functions And Types
>
> ============================
>
> Strings
>
> -------
>
>
> [...]

Okay.

> Bools
>
> -----
>
> [...]

Okay.

> 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.

This is about questioning built-in functions in general, right? That 
didn't come across fast. Maybe, something like this could help:

"and functions (especially the built-in functions) have their advantages".

> Other Language Features
>
> =======================
>
>
>
> The interactive interpreter
>
> ---------------------------
>
> [...]

Really? Who cares anyway? Nevermind, it's okay.

> Copyright
>
> =========
>
>
>
> This document has been placed in the public domain.
>


Generally speaking, I would rather describe this document as the 
"Guideline for Python-Ideas" which should be promoted upfront. I also 
get the impression that this document could use some conciseness and 
focus if you were to push it forward as "things that won't change". 
Otherwise, it just looks more like a guideline. (which I welcome as you 
can imagine)

Furthermore, I still don't know if an informational PEP is the right 
platform this kind of document especially considering the title, the 
circumstances by which it was born and the purpose it is supposed to serve.

Best regards,
Sven