[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 

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 
`_

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

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 
`_ ,

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 
`_

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 
`_

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 
`_

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 
`_

for more details.





Significant indentation

---



`Significant indentation 
`_

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 
`_

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 benefi

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

[Chris Angelico]

On Thu, Jan 12, 2017 at 1:37 PM, 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.
>
>

+1. Sits in a similar place to PEP 3099; can some sort of
appropriate/memorable number be picked for this?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Oleg Broytman]

On Thu, Jan 12, 2017 at 01:37:41PM +1100, Steven D'Aprano  
wrote:
> Explicit self
> -
> 
> Explicit ``self`` is a feature, not a bug.  See the
> `FAQ 
> `_
> for more detail.

   If one thinks that ``self`` is too long and tedious to write she can
use ``s`` instead.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@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/

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

[Chris Barker]

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  wrote:

> On Thu, Jan 12, 2017 at 01:37:41PM +1100, Steven D'Aprano <
> st...@pearwood.info> wrote:
> > Explicit self
> > -
> >
> > Explicit ``self`` is a feature, not a bug.  See the
> > `FAQ  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 Broytmanhttp://phdru.name/p...@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.bar...@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/

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

[Mikhail V]

On 12 January 2017 at 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?
>

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

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

[Pavol Lisy]

On 1/12/17, Steven D'Aprano  wrote:


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

Except Python 4 would come.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[INADA Naoki]

> 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  
> `_,
>
> and functions have their advantages.  See the
>
> `FAQ 
> `_
>
> 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/

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

[Nick Timkovich]

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

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

[Oleg Broytman]

On Thu, Jan 12, 2017 at 12:42:46AM -0600, Nick Timkovich 
 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 
> 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  > 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 Broytmanhttp://phdru.name/p...@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/

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

[Greg Ewing]

Chris Barker wrote:

Frequently Asked Criticisms


Doesn't quite make sense -- one doesn't "ask" criticisms.

How about:

FCLAP - Frequent Criticisms Levelled Against Python

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

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

[Paul Moore]

On 12 January 2017 at 04:39, Mikhail V  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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

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

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric Fahlgren]

On Wed, Jan 11, 2017 at 8:28 PM, Chris Barker  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/

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

[Mark E. Haase]

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:

> Hi, this appears to be your first post to python-ideas. 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. 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.
>
> 1. https://mail.python.org/mailman/listinfo/python-list

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 
wrote:

>
>
> On Wed, Jan 11, 2017 at 8:28 PM, Chris Barker 
> 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/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Barker]

On Wed, Jan 11, 2017 at 10:48 PM, Greg Ewing 
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.bar...@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/

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

[Alexandre Brault]

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
> mailto:greg.ew...@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.bar...@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/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Todd]

On Wed, Jan 11, 2017 at 9:37 PM, 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?
>
>
>
>
>
>
>
>
>
> * * * * * * * * * *
>
>
>
>
>
> PEP: XXX
>
> Title: Things that won't change in Python
>
> Version: $Revision$
>
> Last-Modified: $Date$
>
> Author: Steven D'Aprano 
>
> 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  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  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  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  peps/pep-3105/>`_
>
> for more details.
>
>
>
>
>
> Significant indentation
>
> ---
>
>
>
> `Significant indentation  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

Re: [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 

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 
`_

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

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 
`_ ,

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  
`_,

and functions have their advantages.  See the

`FAQ 
`_

for more detail.


This is about questioning built-in functions in general, right? That 
didn't come acro

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

[Pavol Lisy]

On 1/12/17, Todd  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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Todd]

On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze  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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On 12 January 2017 at 19:33, Sven R. Kunze  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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mikhail V]

On 12 January 2017 at 20:09, Todd  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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Erik]

On 12/01/17 19:51, Todd wrote:


On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze mailto:srku...@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/

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

[Guido van Rossum]

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  wrote:

> On 12/01/17 19:51, Todd wrote:
>
>>
>> On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze > > 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)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Barker - NOAA Federal]

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

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

[Stephen J. Turnbull]

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

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Coghlan]

On 13 January 2017 at 12:43, Stephen J. Turnbull
 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.html
> 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   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Thu, 12 Jan 2017 at 20:05 Nick Coghlan  wrote:

> On 13 January 2017 at 12:43, Stephen J. Turnbull
>  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.html
> > 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 .
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Barry Warsaw]

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


pgpmYyHMRfJQQ.pgp
Description: OpenPGP digital signature
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/