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 <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.
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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
