Things that won't change (proposed PEP)
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@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:
On Thu, Jan 12, 2017 at 1:37 PM, Steven D'Aprano <steve@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.
+1. Sits in a similar place to PEP 3099; can some sort of appropriate/memorable number be picked for this? ChrisA
On Thu, Jan 12, 2017 at 01:37:41PM +1100, Steven D'Aprano <steve@pearwood.info> wrote:
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.
If one thinks that ``self`` is too long and tedious to write she can use ``s`` instead. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
I think this is a fine idea, but I also think we could use a more verbose FAC: Frequently Asked Criticisms Some of the same things, but it would focus on the "why" of many of the issues. Many of the things people (newbies, mostly) complain about are simply taste, or legacy that isn't worth changing. But many are deliberate design decisions that were thoroughly thought out, and have been well explained in various places (i.e. zero-based indexing and open-on-the-right slicing). It would be good to have it all in one place. Maybe this PEP could be extended to include that, but it doesn't feel PEP-like to me. -CHB On Wed, Jan 11, 2017 at 7:17 PM, Oleg Broytman <phd@phdru.name> wrote:
On Thu, Jan 12, 2017 at 01:37:41PM +1100, Steven D'Aprano < steve@pearwood.info> wrote:
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.
If one thinks that ``self`` is too long and tedious to write she can use ``s`` instead.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Greg Ewing writes:
Chris Barker wrote:
Frequently Asked Criticisms
Doesn't quite make sense -- one doesn't "ask" criticisms.
How about:
FCLAP - Frequent Criticisms Levelled Against Python
It reads better if you don't insist that they be frequent. (This may only play in America.)
Stephen J. Turnbull wrote:
Greg Ewing writes:
FCLAP - Frequent Criticisms Levelled Against Python
It reads better if you don't insist that they be frequent. (This may only play in America.)
Criticisms Frequently Levelled Against Python would be another possibility... -- Greg
On Jan 13, 2017, at 11:20 AM, Greg Ewing wrote:
Criticisms Frequently Levelled Against Python
Missteps Or Nonfeatures Guido Obviously Ordered, Saddling Everyone (Yes, okay, I know python's aren't venomous, but never let facts get in the way of a good, bad, tortured, or mentally mushed Friday-evening backronym.) Cheers, -Barry
On Wed, Jan 11, 2017 at 10:48 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Chris Barker wrote:
Frequently Asked Criticisms
Doesn't quite make sense -- one doesn't "ask" criticisms.
I know, but I like that you can pronounce it the same a "FAQ"
FCLAP - Frequent Criticisms Levelled Against Python
Sure -- the title is the least important bit.... -CHB
-- Greg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Frequently Addressed Criticisms would solve both issues, imo Alex On 2017-01-12 12:18 PM, Chris Barker wrote:
On Wed, Jan 11, 2017 at 10:48 PM, Greg Ewing <greg.ewing@canterbury.ac.nz <mailto:greg.ewing@canterbury.ac.nz>> wrote:
Chris Barker wrote:
Frequently Asked Criticisms
Doesn't quite make sense -- one doesn't "ask" criticisms.
I know, but I like that you can pronounce it the same a "FAQ"
FCLAP - Frequent Criticisms Levelled Against Python
Sure -- the title is the least important bit....
-CHB
-- Greg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org <mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov <mailto:Chris.Barker@noaa.gov>
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Wed, Jan 11, 2017 at 8:28 PM, Chris Barker <chris.barker@noaa.gov> wrote:
Many of the things people (newbies, mostly) complain about are simply taste, or legacy that isn't worth changing.
A lot of that sort of thing is idiomatic, so I point people here and say "just do it that way and you'll be happier in the long run." http://stupidpythonideas.blogspot.com/2015/05/why-following-idioms-matters.h...
Hi, this appears to be your first post to python-ideas. This purpose of
I don't think an informational PEP would make threads like Python Review shorter and/or more productive. The OP clearly didn't do much research, so it seems unlikely he would read an informational PEP. Moreover, the bikeshedding about what goes into this PEP will inevitably lead to a troll who isn't satisfied with the explanation of a particular item, or notices that a particular item isn't included in the PEP, and then we're right back to the same problem: litigating Python complaints that have already been discussed many times on this list. We can't change everybody on the internet, but we might be able to change our own behavior. In that spirit, maybe we just need a canned reply that can be used when a thread has indicators of low quality: this list is to discuss speculative language ideas for Python. If an idea gains traction, it can then be discussed and honed into a detailed proposal. Your post does not fit with the purpose of the list, either because it is too broad or because it doesn't contain enough technical details about your proposal. You may wish to improve your proposal by focusing on a single subject, researching historical conversations on that subject, and adding more technical details. Alternatively, you may wish to post on python-list[1] instead, which is a general purpose list that does not have the same constraints as this list.
As a reminder to other list users, please do not encourage low-quality
posts by engaging with them.
Stack Overflow does something similar, where they have canned responses to low-quality questions. This makes it easy for the community to self-moderate in a respectful manner. On Thu, Jan 12, 2017 at 11:16 AM, Eric Fahlgren <ericfahlgren@gmail.com> wrote:
On Wed, Jan 11, 2017 at 8:28 PM, Chris Barker <chris.barker@noaa.gov> wrote:
Many of the things people (newbies, mostly) complain about are simply taste, or legacy that isn't worth changing.
A lot of that sort of thing is idiomatic, so I point people here and say "just do it that way and you'll be happier in the long run."
http://stupidpythonideas.blogspot.com/2015/05/why- following-idioms-matters.html
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Mark E. Haase writes:
I don't think an informational PEP would make threads like Python Review shorter and/or more productive. The OP clearly didn't do much research, so it seems unlikely he would read an informational PEP.
But just saying "do your research" (which is quite reasonable without the informational PEP) is much less friendly than including the URL to the informational PEP in the kind of "canned response" you suggest. That's what Steven is aiming at. I'm not sure that a PEP is the best format, as the normal PEP process is not a good match for something that is likely to need to be updated as "good syntax" is discovered for ideas formerly considered un-Pythonic and other languages come up with neat new ideas that don't have obvious Pythonic syntax. Andrew Barnert's blog post (thanks, Chris!) http://stupidpythonideas.blogspot.com/2015/05/why-following-idioms-matters.h... is a good start, and Nick Coghlan's "Curious Efficiency" blog has related material, I think. Perhaps pointers to those would be good.
Moreover, the bikeshedding about what goes into this PEP will inevitably lead to a troll who isn't satisfied with the explanation of a particular item, or notices that a particular item isn't included in the PEP, and then we're right back to the same problem: litigating Python complaints that have already been discussed many times on this list.
I don't see why that has to be the case. The canned response here is "Thank you for your suggestion. The issue tracker is right over that-a-way." A suggestion for your canned response:
Hi, this appears to be your first post to python-ideas.
Unfortunately, there are a number of folks around who enjoy discussing non-starters to death. That's insulting to them, and therefore against the spirit of the CoC. I'd remove that, and write
This purpose of this list is to discuss speculative language ideas for Python. If an idea gains traction, it can then be discussed and honed into a detailed proposal.
followed by Your post does not present a clear, coherent proposal. and
Your post does not fit with the purpose of the list, either because it is too broad or because it doesn't contain enough technical details about your proposal. You may wish to improve your proposal by focusing on a single subject, researching historical conversations on that subject, and adding more technical details. Alternatively, you may wish to post on python-list[1] instead, which is a general purpose list that does not have the same constraints as this list.
Of course this presentation is broken, the grammar can be improved easily.
Stack Overflow does something similar, where they have canned responses to low-quality questions. This makes it easy for the community to self-moderate in a respectful manner.
We have a few of those already. This would be a useful addition.
On 13 January 2017 at 12:43, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Mark E. Haase writes:
I don't think an informational PEP would make threads like Python Review shorter and/or more productive. The OP clearly didn't do much research, so it seems unlikely he would read an informational PEP.
But just saying "do your research" (which is quite reasonable without the informational PEP) is much less friendly than including the URL to the informational PEP in the kind of "canned response" you suggest. That's what Steven is aiming at.
I'm not sure that a PEP is the best format, as the normal PEP process is not a good match for something that is likely to need to be updated as "good syntax" is discovered for ideas formerly considered un-Pythonic and other languages come up with neat new ideas that don't have obvious Pythonic syntax. Andrew Barnert's blog post (thanks, Chris!) http://stupidpythonideas.blogspot.com/2015/05/why-following-idioms-matters.h... is a good start, and Nick Coghlan's "Curious Efficiency" blog has related material, I think. Perhaps pointers to those would be good.
Expanding on https://docs.python.org/devguide/langchanges.html would likely be a more useful format than an informational PEP. As a starting point, https://docs.python.org/devguide/faq.html#suggesting-changes should likely be consolidated into that page, and the FAQ entry simplified into a link to a new subsection on that page. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, 12 Jan 2017 at 20:05 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 13 January 2017 at 12:43, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Mark E. Haase writes:
I don't think an informational PEP would make threads like Python Review shorter and/or more productive. The OP clearly didn't do much research, so it seems unlikely he would read an informational PEP.
But just saying "do your research" (which is quite reasonable without the informational PEP) is much less friendly than including the URL to the informational PEP in the kind of "canned response" you suggest. That's what Steven is aiming at.
I'm not sure that a PEP is the best format, as the normal PEP process is not a good match for something that is likely to need to be updated as "good syntax" is discovered for ideas formerly considered un-Pythonic and other languages come up with neat new ideas that don't have obvious Pythonic syntax. Andrew Barnert's blog post (thanks, Chris!)
http://stupidpythonideas.blogspot.com/2015/05/why-following-idioms-matters.h...
is a good start, and Nick Coghlan's "Curious Efficiency" blog has related material, I think. Perhaps pointers to those would be good.
Expanding on https://docs.python.org/devguide/langchanges.html would likely be a more useful format than an informational PEP.
As a starting point, https://docs.python.org/devguide/faq.html#suggesting-changes should likely be consolidated into that page, and the FAQ entry simplified into a link to a new subsection on that page.
Do realize the FAQ is gutted in the github branch so make sure you look at that version of the devguide to know what's planned: https://cpython-devguide.readthedocs.io/en/github/index.html .
On 12 January 2017 at 03:37, Steven D'Aprano <steve@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?
Excellent idea, I was going to ask about such list during my own attempts here. And my first though is about "will not change". Like: never ever change or like: will not change in 10 years or 20 years. And on this occassion, I'd look forward to some alternative informal proposals repository. For example something like "futuristic corner" for some unusual topics but potentially useful for future development. Now there is "informational PEP" section, but not very clear if it is more informal than normal PEPs or how would one go with merely marginal topics, including those things, which will most obviously not change. And probably your idea is exactly against this attitude, hard to say. Mikhail
On 12 January 2017 at 04:39, Mikhail V <mikhailwas@gmail.com> wrote:
And my first though is about "will not change". Like: never ever change or like: will not change in 10 years or 20 years.
Like: "Please don't waste people's time trying to start a discussion about them". In 10 or 20 years, if opinions have changed, the PEP can be updated. Paul
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
for more detail.
I don't like this FAQ entry. See this issue: https://bugs.python.org/issue27671
Why mention sys.ps1 == '>>> ', is that some inside joke I'm unaware of? That is one of the easier things to modify (with a sitecustomize.py or whatever). On Thu, Jan 12, 2017 at 12:03 AM, INADA Naoki <songofacandy@gmail.com> wrote:
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.
I don't like this FAQ entry. See this issue: https://bugs.python.org/ issue27671 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Jan 12, 2017 at 12:42:46AM -0600, Nick Timkovich <prometheus235@gmail.com> wrote:
Why mention sys.ps1 == '>>> ', is that some inside joke I'm unaware of? That is one of the easier things to modify (with a sitecustomize.py or whatever).
With PYTHONSTARTUP.
On Thu, Jan 12, 2017 at 12:03 AM, INADA Naoki <songofacandy@gmail.com> wrote:
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.
I don't like this FAQ entry. See this issue: https://bugs.python.org/ issue27671
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
On Wed, Jan 11, 2017 at 9:37 PM, Steven D'Aprano <steve@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 <steve@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).
On 1/12/17, Todd <toddrjen@gmail.com> wrote:
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.
This one bring question how deep this PEP could be because we could show what is "impossible" to change but also how to satisfy some needs without changing language. & and | are non-short-circuiting and thanks to fact that boolean is subclass of int (see other section of this PEP!) we could use it nicely.
On 12 January 2017 at 20:09, Todd <toddrjen@gmail.com> wrote:
4. I think either adding a bit more detail about the rationale for the decisions,
Would be nice. But then someone must tinker with it. 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.
I think this means that $ sign does make the code look ugly and distracts from reading. So it is avoided not to mess up readability. Mikhail
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@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
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
On 12 January 2017 at 19:33, Sven R. Kunze <srkunze@mail.de> wrote:
This a very absolute-sounding title. Maybe inserting a "(most likely)" between "that" and "won't" will give it the right nudge.
Well, the whole point of the document is to stop people falsely hoping that they can "persuade" people to change things, so absolute statements seem appropriate here. Paul
On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze <srkunze@mail.de> wrote:
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.
There is no "censorship" or "banning thoughts" going on here. Even with this PEP, people are free to think about and talk about how Python could work differently all they want. What this PEP does is tell them that certain decisions have been made about how the Python language is going to work, so they should be aware that such talk isn't going to actually result in any changes to the language. It is a matter about being honest and realistic about what Python is and is not, about what parts of the language are considered defining features. No one will be banned from telling python developers they think one of these features should be changed, but they can know ahead of time that such requests won't be productive and will be able to include that information in their decision about how much time to spend on such requests. So I think the importance of this PEP extend beyond just the python-ideas list.
On 12/01/17 19:51, Todd wrote:
On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze <srkunze@mail.de <mailto:srkunze@mail.de>> wrote: First of all, I am anti-censor and pro-change.
There is no "censorship" or "banning thoughts" going on here. Even with this PEP, people are free to think about and talk about how Python could work differently all they want. What this PEP does is tell them that certain decisions have been made about how the Python language is going to work, so they should be aware that such talk isn't going to actually result in any changes to the language.
By saying that "these are things that will not change", then you _are_ sort of banning talk about them (if, as you assert, "such talk isn't going to actually result in any changes to the language" then you are saying don't waste your breath, we won't even consider your arguments). I think I get Sven's point. A long time ago, someone probably said "Python will never have any sort of type declarations.". But now there is type hinting. It's not the same thing, I know, but such a declaration in a PEP might have prevented people from even spending time considering hinting. Instead, if the PEP collected - for each 'frequently' suggested change - a summary of the reasons WHY each aspect is designed the way it is (with links to archived discussions or whatever) then that IMO that would be a good resource to cite in a canned response to such suggestions. It's not that "these things will never change", it's more of a "you need to provide a solid argument why your suggestion is different to, and better than, the cited suggestions that have already been rejected". Probably a lot of work to gather all the references though. But it could start out with one or two and grow from there. Add to it as and when people bring up the same old stuff next time. E.
I've not followed this discussion closely, but I would assume that for most things on the "will never change" list the explanation is simply that the cost of changing it while maintaining backward compatibility is too high compared to the benefit of fixing the problem (regardless of whether it really is a problem). People who come in with enthusiastic proposals to fix some pet peeve usually don't have the experience needed to appreciate the difficulty in maintaining backwards compatibility. (A really weird disconnect from reality happens when this is mentioned in the same breath as "please fix the Python 2 vs. 3 problem". :-) I would also guess that for things that are actually controversial (meaning some people hate a feature that other people love), it's much easier to explain why it's too late to change than it is to provide an objective argument for why the status quo is better. Often the status quo is not better per se, it's just better because it's the status quo. from __future__ import no_colons # :-) On Thu, Jan 12, 2017 at 4:57 PM, Erik <python@lucidity.plus.com> wrote:
On 12/01/17 19:51, Todd wrote:
On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze <srkunze@mail.de <mailto:srkunze@mail.de>> wrote: First of all, I am anti-censor and pro-change.
There is no "censorship" or "banning thoughts" going on here. Even with
this PEP, people are free to think about and talk about how Python could work differently all they want. What this PEP does is tell them that certain decisions have been made about how the Python language is going to work, so they should be aware that such talk isn't going to actually result in any changes to the language.
By saying that "these are things that will not change", then you _are_ sort of banning talk about them (if, as you assert, "such talk isn't going to actually result in any changes to the language" then you are saying don't waste your breath, we won't even consider your arguments).
I think I get Sven's point. A long time ago, someone probably said "Python will never have any sort of type declarations.". But now there is type hinting. It's not the same thing, I know, but such a declaration in a PEP might have prevented people from even spending time considering hinting.
Instead, if the PEP collected - for each 'frequently' suggested change - a summary of the reasons WHY each aspect is designed the way it is (with links to archived discussions or whatever) then that IMO that would be a good resource to cite in a canned response to such suggestions.
It's not that "these things will never change", it's more of a "you need to provide a solid argument why your suggestion is different to, and better than, the cited suggestions that have already been rejected".
Probably a lot of work to gather all the references though. But it could start out with one or two and grow from there. Add to it as and when people bring up the same old stuff next time.
E.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
By saying that "these are things that will not change",
I agree -- these are not exactly " things that will not change" as they are: "Things that have been discussed (often ad nausium) and considered and definitively rejected" And many of them are: "Part of what makes Python Python" I think some wordsmithing is in order to make that clear. -CHB
participants (22)
-
Alexandre Brault -
Barry Warsaw -
Brett Cannon -
Chris Angelico -
Chris Barker -
Chris Barker - NOAA Federal
-
Eric Fahlgren -
Erik -
Greg Ewing -
Guido van Rossum -
INADA Naoki -
Mark E. Haase -
Mikhail V -
Nick Coghlan -
Nick Timkovich -
Oleg Broytman -
Paul Moore -
Pavol Lisy -
Stephen J. Turnbull -
Steven D'Aprano -
Sven R. Kunze -
Todd