Re: [Python-Dev] Slow down...

[Jeff Hardy]

On Mon, May 7, 2018 at 10:21 AM, Glenn Linderman  wrote:
> On 5/7/2018 7:59 AM, Eric Snow wrote:
>
> On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan  wrote:
>
> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
> language moratorium could be a very good idea.
>
> Note that the PEP specifically applies to "syntax, semantics, and
> built-ins".  Here's the full abstract [1]:
>
> This PEP proposes a temporary moratorium (suspension) of all changes to
> the
> Python language syntax, semantics, and built-ins for a period of
> at least two
> years from the release of Python 3.1. In particular, the moratorium
> would
> include Python 3.2 (to be released 18-24 months after 3.1) but allow
> Python
> 3.3 (assuming it is not released prematurely) to once again include
> language
> changes.
>
> This suspension of features is designed to allow non-CPython
> implementations
> to "catch up" to the core implementation of the language, help ease
> adoption
> of Python 3.x, and provide a more stable base for the community.
>
> -eric
>
> Here's my "lightning" response to a "lightning talk" about a moratorium:
>
> So if other implementations didn't catch up during the last moratorium,
> either the moratorium then was lifted too soon, or the other implementations
> don't really want to catch up, or the thought that they should catch up was
> deemed less important than making forward progress with the language. Have
> any of those opinions changed?

Speaking as the maintainer of IronPython during the last moratorium:
while catching up was certainly desirable, there simply wasn't enough
person-power to do it any reasonable amount of time (I'm not sure any
implementation besides PyPy even has yield-from, let alone async).
Between fixing issues in 2.x branches, trying to implement 3.x
features, and dealing with underlying platform churn I don't think
even two years was ever realistic. Plus, every feature has to be
considered with how it works in Python and the other platform (like,
what sort of fun .NET interop can we do with type annotations?).

Another moratorium would probably have the same (lack of) effect.
Better, IMO, to just raise the bar on expensive features and let them
catch up naturally.

- Jeff
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Serhiy Storchaka]

09.05.18 14:35, Antoine Pitrou пише:

I proposed the idea in another thread that Python had reached "peak
syntax" and maybe it was time to consider the core language essentially
mature.  Of course, we don't know what the future will bring and
perhaps some fundamentally new programming idiom will appear in the
next years that deserve implementing in Python.


"If you want to add a new syntax feature, first remove two old syntax 
features."


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Steven D'Aprano]

On Wed, May 09, 2018 at 01:35:53PM +0200, Antoine Pitrou wrote:

> > > I would remove "for a while".  "Try to avoid major language features"
> > > sounds good.  
> > 
> > It sounds good, until you ask about "What if we had that policy from 
> > the beginning?"
[...]
> "Try to avoid" would make it more of a general guideline than a hard
> rule, IMHO.

Fair enough. But it really depends on how hard we try: too hard, or not 
hard enough?

*wink*

-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Antoine Pitrou]

On Wed, 9 May 2018 14:25:06 +1000
Steven D'Aprano  wrote:
> On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote:
> > On Mon, 07 May 2018 19:19:28 +
> > Ryan Gonzalez  wrote:  
> > > 10 years feels like a simultaneously long and arbitrary limit. IMO a 
> > > policy
> > > of "try to avoid major language features for a while" would work better.  
> > 
> > I would remove "for a while".  "Try to avoid major language features"
> > sounds good.  
> 
> It sounds good, until you ask about "What if we had that policy from 
> the beginning?"
> 
> Let's see what sort of language features we would miss out on if we 
> avoided language features because there was an existing alternative:
[...]

"Try to avoid" would make it more of a general guideline than a hard
rule, IMHO.

I proposed the idea in another thread that Python had reached "peak
syntax" and maybe it was time to consider the core language essentially
mature.  Of course, we don't know what the future will bring and
perhaps some fundamentally new programming idiom will appear in the
next years that deserve implementing in Python.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Greg Ewing]

Serhiy Storchaka wrote:

Like tab-delimited tables.


No, the obvious way to do tables is to allow
HTML-marked-up source code.

There would be other benefits to that as well. For
example we could decree that all keywords must be
formatted in bold, and then there would be
no trouble adding new keywords.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Ben Finney]

Serhiy Storchaka  writes:

> 09.05.18 07:25, Steven D'Aprano пише:
> > If we could look forward to 2028, when we're running Python 3.14 or so
> > (4.7 if you prefer), how many fantastic language features that we cannot
> > bear to give up would we be missing out on?
>
> Like tab-delimited tables.

Cheeky :-)

(For those who are not closely following comp.lang.python, I am pretty
sure Serhiy is wryly referring to an ongoing thread in that forum.
Someone is arguing that Python should grow a U+0009-delimited syntax for
tabular data, and quickly demonstrated a lack of interest in the familir
reasons why this is a bad idea. The thread is already past the point of
calm discussion, so I am not linking to it because it's not worth wading
into.)

-- 
 \ “I wish I had a dollar for every time I spent a dollar, because |
  `\   then, yahoo!, I'd have all my money back.” —Jack Handey |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Tim Peters]

[Steven D'Aprano ]
> ...
> If we could look forward to 2028, when we're running Python 3.14 or so
> (4.7 if you prefer), how many fantastic language features that we cannot
> bear to give up would we be missing out on?

This, for just one:

k = 6 if >!{myobj.meth(arg)[2]} elsenone 7 elsenan 8 else 5

Which is really annoying to write today, but would be much clearer
with binding expressions:

if myobj is None:
k = 7
elif (t := myobj.meth) is None:
k = 7
elif (t := t(arg)) is None:
k = 7
elif (t := t[2]) is None:
k = 7
eiif math.isnan(t):
k = 8
elif t:
k = 6
else:
k = 5

The future is blindingly bright :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Serhiy Storchaka]

09.05.18 07:25, Steven D'Aprano пише:

If we could look forward to 2028, when we're running Python 3.14 or so
(4.7 if you prefer), how many fantastic language features that we cannot
bear to give up would we be missing out on?


Like tab-delimited tables.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Steven D'Aprano]

On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote:
> On Mon, 07 May 2018 19:19:28 +
> Ryan Gonzalez  wrote:
> > 10 years feels like a simultaneously long and arbitrary limit. IMO a policy
> > of "try to avoid major language features for a while" would work better.
> 
> I would remove "for a while".  "Try to avoid major language features"
> sounds good.

It sounds good, until you ask about "What if we had that policy from 
the beginning?"

Let's see what sort of language features we would miss out on if we 
avoided language features because there was an existing alternative:

- async/await ("use the asyncio library")

- comprehensions ("just write a loop")

- True/False builtins ("just define your own constants at the top
  of the module")

- f-strings ("just use str.format")

- yield from ("most of the time you can just use 
  ``for x in thing: yield x``, the rest of the cases are
  too obscure and unimportant to justify new syntax")

- with statements and context managers ("just use a try...
  finally")

- ternary if ("just re-write it as a if...else block, or use
  the ``x or y and z`` trick")

- closures ("just write a class")

- yield as an expression for sending values into a generator
  (a pre-async kind of coroutine) ("just write a class")

- function annotations ("just use one of three or four competing
  standards for docstring annotations")


The only language feature I can think of that had no way of doing it 
before being added to the library was Unicode support.

So we'd effectively have Python 1.5 plus Unicode.

If we could look forward to 2028, when we're running Python 3.14 or so 
(4.7 if you prefer), how many fantastic language features that we cannot 
bear to give up would we be missing out on?



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Steven D'Aprano]

On Mon, May 07, 2018 at 10:21:13AM -0700, Glenn Linderman wrote:

> Dan's original comment about language versus library is interesting, 
> though. It is probably true that one should resist adding language where 
> library suffices, but sometimes a lack of certain expressiveness in the 
> language causes cumbersome implementations of library routines to 
> achieve the goal.

+1


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[David Mertz]

This seems like a rather bad idea. None of the core changes in the last few
versions were on the radar 10 years in advance. And likewise, no one really
knows what new issues will become critical over the next 10.

The asyncio module and the async/await keywords only developed as important
concerns for a year or two before they became part of the language.
Likewise for type annotations. Neither is used by most Python programmers,
but for a subset, they are very important.

I supposed f-strings are incidental. We could have lived without them (I
myself doughty opposed "another way to do it"). But they do make code nicer
at the cost of incompatible syntax. Likewise underscores in numbers like
17_527_103. Not everyone needs the __mmul__() operator. But for linear
algebra, 'a @ b.T' is better than 'np.dot(a, b.T)'.

On Mon, May 7, 2018, 3:10 PM Craig Rodrigues  wrote:

>
>
> On Sun, May 6, 2018 at 7:35 PM Nick Coghlan  wrote:
>
>>
>> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
>> language moratorium could be a very good idea. Between matrix
>> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
>> type hinting for variable assignments, we've had quite a bit of syntactic
>> churn in the past few releases, and the rest of the ecosystem really hasn't
>> caught up on it all yet (and that's not just other implementations - it's
>> training material, online courses, etc, etc).
>>
>> If we're going to take such a step, now's also the time to do it, since
>> 3.8 feature development is only just getting under way, and if we did
>> decide to repeat the language moratorium, we could co-announce it with the
>> Python 3.7 release.
>>
>>
> Would it be reasonable to request a 10 year moratorium on making changes
> to the core Python language,
> and for the next 10 years only focus on things that do not require core
> language changes,
> such as improving/bugfixing existing libraries, writing new libraries,
> improving tooling, improving infrastructure (PyPI),
> improving performance, etc., etc.?
>
> There are still many companies still stuck on Python 2, so giving 10 years
> of breathing room
> for these companies to catch up to Python 3 core language, even past 2020
> would be very helpful.
>
> --
> Craig
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Eric V. Smith]

> On May 8, 2018, at 11:48 AM, Brett Cannon  wrote:
> 
> 
> 
>> On Tue, 8 May 2018 at 08:26 Craig Rodrigues  wrote:
>>> On Mon, May 7, 2018 at 2:24 PM Barry Warsaw  wrote:
>>> On May 7, 2018, at 11:49, Craig Rodrigues  wrote:
>>> > 
>>> > Would it be reasonable to request a 10 year moratorium on making changes 
>>> > to the core Python language,
>>> > and for the next 10 years only focus on things that do not require core 
>>> > language changes,
>>> > such as improving/bugfixing existing libraries, writing new libraries, 
>>> > improving tooling, improving infrastructure (PyPI),
>>> > improving performance, etc., etc.?
>>> 
>>> IMHO, no.
>>> 
>>> I don’t believe that the way for Python to remain relevant and useful for 
>>> the next 10 years is to cease all language evolution.  Who knows what the 
>>> computing landscape will look like in 5 years, let alone 10?  Something as 
>>> arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the 
>>> language.
>>> 
>>> But I do think it makes sense to think about how Python-the-language and 
>>> CPython-the-reference implementation can better balance the desire to 
>>> evolve vs the need to concentrate on improving what we’ve got.  With that 
>>> in mind, it does make sense to occasionally use a moratorium release to 
>>> focus on tech debt, cleaning up the stdlib, improve performance, etc.
>>> 
>>> CPython’s 18 month release cycle has served us well for a long time, but I 
>>> do think it’s time to discuss whether it will still be appropriate moving 
>>> forward.  I’m not saying it is or isn’t, but with the release of 3.7, I 
>>> think it’s a great time to explore our options.
>>> 
>> 
>> 10 years is a long time for many types of applications, such as web server 
>> and desktop applications
>> where regular and somewhat frequent upgrades can happen.
>> However, I have worked on embedding Python in networking and storage devices.
>> It is true that many of these types of devices can also have their software 
>> upgraded,
>> but often the frequency of such upgrades is much slower than for 
>> conventional web server and desktop applications.
>> Upgrades of these devices usually spans user-space and kernel/device 
>> drivers, so
>> upgrades are usually done more cautiously and less frequently.
>> 
>> For Python 2.x, the ship has sailed.  However, 10 years from now, if the 
>> Python language
>> is pretty much the same as Python 3.7 today, that would be nice.
> 
> Then feel free to stay on Python 3.7. We have versioned releases so people 
> can choose to do that. :)

Also, you can pay people to support old versions, and sometimes even backport 
features you need. So I think this use case is already covered. You just can’t 
expect to hold up language development because you want to have a stable 
supported version. 

Eric 

>  
>> 
>> I'm not stuck on the number "10 years", but I am just throwing it out there 
>> as a draft proposal.
>> So even 5-8 year moratorium would be nice to strive for.
> 
> Timespans of that length are still too long to freeze the language. Look at 
> it this way: node.js 0.10.0 was released 5 years ago and now it's a thing. If 
> we had not moved forward and added async/await in Python 3.5 -- which was 
> only 3 years ago -- but instead froze ourselves for 5 years would we be 
> considered relevant in the networking world like we are, or viewed as 
> somewhat as a dinosaur?
> 
> I realize the embedded world moves at a different pace (as well as other 
> groups of developers), but that doesn't mean we have to move at the speed of 
> our slowest adopters to punish those willing and wanting newer features.
>  
>> 
>> 
>> Outside of the embedded space, I will give another example where folks in 
>> industry are behind.
>> I don't want to pick on a particular vendor, but from April 24-26, I 
>> attended training sessions at RedisConf18 in San Francisco.
>> During the training sessions, multiple sample Python code examples were 
>> given for accessing the Redis database.
>> The instructor thought that the code examples worked in Python 3, but in 
>> fact, they only worked in Python 2 mostly due to
>> bytes/unicode issues.  During the class, I fixed the examples for Python 3 
>> and submitted the patches to the instructor,
>> who gratefully accepted my patches.  However, there are going to be many, 
>> many users of Redis out there who
>> maybe will not upgrade their Python code for newer versions of Python for 
>> many years.
> 
> Why is Redis specifically going to be behind specifically? Are they embedding 
> the interpreter?
>  
>> 
>> Besides Redis users, I am seeing all sorts of communities and companies 
>> which are behind in terms of having working
>> code and documentation that works on latest Python 3.  It is going to take 
>> YEARS for all these communities and companies
>> to catch up (if ever).
> 
> And that's fine. If they want to 

Re: [Python-Dev] Slow down...

[Brett Cannon]

On Tue, 8 May 2018 at 08:26 Craig Rodrigues  wrote:

> On Mon, May 7, 2018 at 2:24 PM Barry Warsaw  wrote:
>
>> On May 7, 2018, at 11:49, Craig Rodrigues  wrote:
>> >
>> > Would it be reasonable to request a 10 year moratorium on making
>> changes to the core Python language,
>> > and for the next 10 years only focus on things that do not require core
>> language changes,
>> > such as improving/bugfixing existing libraries, writing new libraries,
>> improving tooling, improving infrastructure (PyPI),
>> > improving performance, etc., etc.?
>>
>> IMHO, no.
>>
>> I don’t believe that the way for Python to remain relevant and useful for
>> the next 10 years is to cease all language evolution.  Who knows what the
>> computing landscape will look like in 5 years, let alone 10?  Something as
>> arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the
>> language.
>>
>> But I do think it makes sense to think about how Python-the-language and
>> CPython-the-reference implementation can better balance the desire to
>> evolve vs the need to concentrate on improving what we’ve got.  With that
>> in mind, it does make sense to occasionally use a moratorium release to
>> focus on tech debt, cleaning up the stdlib, improve performance, etc.
>>
>> CPython’s 18 month release cycle has served us well for a long time, but
>> I do think it’s time to discuss whether it will still be appropriate moving
>> forward.  I’m not saying it is or isn’t, but with the release of 3.7, I
>> think it’s a great time to explore our options.
>>
>>
> 10 years is a long time for many types of applications, such as web server
> and desktop applications
> where regular and somewhat frequent upgrades can happen.
> However, I have worked on embedding Python in networking and storage
> devices.
> It is true that many of these types of devices can also have their
> software upgraded,
> but often the frequency of such upgrades is much slower than for
> conventional web server and desktop applications.
> Upgrades of these devices usually spans user-space and kernel/device
> drivers, so
> upgrades are usually done more cautiously and less frequently.
>
> For Python 2.x, the ship has sailed.  However, 10 years from now, if the
> Python language
> is pretty much the same as Python 3.7 today, that would be nice.
>

Then feel free to stay on Python 3.7. We have versioned releases so people
can choose to do that. :)


>
> I'm not stuck on the number "10 years", but I am just throwing it out
> there as a draft proposal.
> So even 5-8 year moratorium would be nice to strive for.
>

Timespans of that length are still too long to freeze the language. Look at
it this way: node.js 0.10.0 was released 5 years ago and now it's a thing.
If we had not moved forward and added async/await in Python 3.5 -- which
was only 3 years ago -- but instead froze ourselves for 5 years would we be
considered relevant in the networking world like we are, or viewed as
somewhat as a dinosaur?

I realize the embedded world moves at a different pace (as well as other
groups of developers), but that doesn't mean we have to move at the speed
of our slowest adopters to punish those willing and wanting newer features.


>
>
> Outside of the embedded space, I will give another example where folks in
> industry are behind.
> I don't want to pick on a particular vendor, but from April 24-26, I
> attended training sessions at RedisConf18 in San Francisco.
> During the training sessions, multiple sample Python code examples were
> given for accessing the Redis database.
> The instructor thought that the code examples worked in Python 3, but in
> fact, they only worked in Python 2 mostly due to
> bytes/unicode issues.  During the class, I fixed the examples for Python 3
> and submitted the patches to the instructor,
> who gratefully accepted my patches.  However, there are going to be many,
> many users of Redis out there who
> maybe will not upgrade their Python code for newer versions of Python for
> many years.
>

Why is Redis specifically going to be behind specifically? Are they
embedding the interpreter?


>
> Besides Redis users, I am seeing all sorts of communities and companies
> which are behind in terms of having working
> code and documentation that works on latest Python 3.  It is going to take
> YEARS for all these communities and companies
> to catch up (if ever).
>

And that's fine. If they want to continue to maintain Python 2 and stay on
it, or simply stick with our final release and never worry about potential
security issues, that's their prerogative. But once again, we shouldn't
have to hold up the entire language for the slowest adopters.


>
> I understand that Python as a language must evolve over time to succeed
> and thrive.  But I would request that
> at least for the next 5-10 years, a moratorium on language changes be
> considered, to allow the world to catch
> up in terms of code, 

Re: [Python-Dev] Slow down...

[Craig Rodrigues]

On Mon, May 7, 2018 at 2:24 PM Barry Warsaw  wrote:

> On May 7, 2018, at 11:49, Craig Rodrigues  wrote:
> >
> > Would it be reasonable to request a 10 year moratorium on making changes
> to the core Python language,
> > and for the next 10 years only focus on things that do not require core
> language changes,
> > such as improving/bugfixing existing libraries, writing new libraries,
> improving tooling, improving infrastructure (PyPI),
> > improving performance, etc., etc.?
>
> IMHO, no.
>
> I don’t believe that the way for Python to remain relevant and useful for
> the next 10 years is to cease all language evolution.  Who knows what the
> computing landscape will look like in 5 years, let alone 10?  Something as
> arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the
> language.
>
> But I do think it makes sense to think about how Python-the-language and
> CPython-the-reference implementation can better balance the desire to
> evolve vs the need to concentrate on improving what we’ve got.  With that
> in mind, it does make sense to occasionally use a moratorium release to
> focus on tech debt, cleaning up the stdlib, improve performance, etc.
>
> CPython’s 18 month release cycle has served us well for a long time, but I
> do think it’s time to discuss whether it will still be appropriate moving
> forward.  I’m not saying it is or isn’t, but with the release of 3.7, I
> think it’s a great time to explore our options.
>
>
10 years is a long time for many types of applications, such as web server
and desktop applications
where regular and somewhat frequent upgrades can happen.
However, I have worked on embedding Python in networking and storage
devices.
It is true that many of these types of devices can also have their software
upgraded,
but often the frequency of such upgrades is much slower than for
conventional web server and desktop applications.
Upgrades of these devices usually spans user-space and kernel/device
drivers, so
upgrades are usually done more cautiously and less frequently.

For Python 2.x, the ship has sailed.  However, 10 years from now, if the
Python language
is pretty much the same as Python 3.7 today, that would be nice.

I'm not stuck on the number "10 years", but I am just throwing it out there
as a draft proposal.
So even 5-8 year moratorium would be nice to strive for.


Outside of the embedded space, I will give another example where folks in
industry are behind.
I don't want to pick on a particular vendor, but from April 24-26, I
attended training sessions at RedisConf18 in San Francisco.
During the training sessions, multiple sample Python code examples were
given for accessing the Redis database.
The instructor thought that the code examples worked in Python 3, but in
fact, they only worked in Python 2 mostly due to
bytes/unicode issues.  During the class, I fixed the examples for Python 3
and submitted the patches to the instructor,
who gratefully accepted my patches.  However, there are going to be many,
many users of Redis out there who
maybe will not upgrade their Python code for newer versions of Python for
many years.

Besides Redis users, I am seeing all sorts of communities and companies
which are behind in terms of having working
code and documentation that works on latest Python 3.  It is going to take
YEARS for all these communities and companies
to catch up (if ever).

I understand that Python as a language must evolve over time to succeed and
thrive.  But I would request that
at least for the next 5-10 years, a moratorium on language changes be
considered, to allow the world to catch
up in terms of code, documentation, and mind/understanding.


Looking back at how the Python 2.7 EOL was extended by 5 years, I would
remind the core Python developers
that it is very easy to underestimate how slow the world is to change their
code, documentation, training,
and understanding  to adapt to new Python versions.  Going slow or imposing
a moratorium wouldn't be such a bad thing.

--
Craig
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Steve Dower]

A moratorium on new features to focus on cleaning up and planning for 
transition away from the 2.7 compatibility features that still exist? The most 
obvious being the libraries that we promised not to remove until 2.7 EOL.

Top-posted from my Windows phone

From: Barry Warsaw
Sent: Monday, May 7, 2018 14:26
To: Python Dev
Subject: Re: [Python-Dev] Slow down...

On May 7, 2018, at 11:49, Craig Rodrigues <rodr...@crodrigues.org> wrote:
> 
> Would it be reasonable to request a 10 year moratorium on making changes to 
> the core Python language,
> and for the next 10 years only focus on things that do not require core 
> language changes,
> such as improving/bugfixing existing libraries, writing new libraries, 
> improving tooling, improving infrastructure (PyPI),
> improving performance, etc., etc.?

IMHO, no.

I don’t believe that the way for Python to remain relevant and useful for the 
next 10 years is to cease all language evolution.  Who knows what the computing 
landscape will look like in 5 years, let alone 10?  Something as arbitrary as a 
10 year moratorium is (again, IMHO) a death sentence for the language.

But I do think it makes sense to think about how Python-the-language and 
CPython-the-reference implementation can better balance the desire to evolve vs 
the need to concentrate on improving what we’ve got.  With that in mind, it 
does make sense to occasionally use a moratorium release to focus on tech debt, 
cleaning up the stdlib, improve performance, etc.

CPython’s 18 month release cycle has served us well for a long time, but I do 
think it’s time to discuss whether it will still be appropriate moving forward. 
 I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a 
great time to explore our options.

Cheers,
-Barry


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[MRAB]

On 2018-05-07 19:49, Craig Rodrigues wrote:



[snip]


Would it be reasonable to request a 10 year moratorium on making changes 
to the core Python language,
and for the next 10 years only focus on things that do not require core 
language changes,
such as improving/bugfixing existing libraries, writing new libraries, 
improving tooling, improving infrastructure (PyPI),

improving performance, etc., etc.?

There are still many companies still stuck on Python 2, so giving 10 
years of breathing room
for these companies to catch up to Python 3 core language, even past 
2020 would be very helpful.



[snip]

I don't see how a 10 year moratorium will help those still on Python 2, 
given that Python 2.7 has been around for almost 8 years already, by 
2020 it will have been 10 years, and it was made clear that it would be 
the last in the Python 2 line.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Barry Warsaw]

On May 7, 2018, at 11:49, Craig Rodrigues  wrote:
> 
> Would it be reasonable to request a 10 year moratorium on making changes to 
> the core Python language,
> and for the next 10 years only focus on things that do not require core 
> language changes,
> such as improving/bugfixing existing libraries, writing new libraries, 
> improving tooling, improving infrastructure (PyPI),
> improving performance, etc., etc.?

IMHO, no.

I don’t believe that the way for Python to remain relevant and useful for the 
next 10 years is to cease all language evolution.  Who knows what the computing 
landscape will look like in 5 years, let alone 10?  Something as arbitrary as a 
10 year moratorium is (again, IMHO) a death sentence for the language.

But I do think it makes sense to think about how Python-the-language and 
CPython-the-reference implementation can better balance the desire to evolve vs 
the need to concentrate on improving what we’ve got.  With that in mind, it 
does make sense to occasionally use a moratorium release to focus on tech debt, 
cleaning up the stdlib, improve performance, etc.

CPython’s 18 month release cycle has served us well for a long time, but I do 
think it’s time to discuss whether it will still be appropriate moving forward. 
 I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a 
great time to explore our options.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Antoine Pitrou]

On Mon, 07 May 2018 19:19:28 +
Ryan Gonzalez  wrote:
> 10 years feels like a simultaneously long and arbitrary limit. IMO a policy
> of "try to avoid major language features for a while" would work better.

I would remove "for a while".  "Try to avoid major language features"
sounds good.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Ryan Gonzalez]

10 years feels like a simultaneously long and arbitrary limit. IMO a policy
of "try to avoid major language features for a while" would work better.

On Mon, May 7, 2018 at 2:11 PM Craig Rodrigues 
wrote:

>
>
> On Sun, May 6, 2018 at 7:35 PM Nick Coghlan  wrote:
>
>>
>> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
>> language moratorium could be a very good idea. Between matrix
>> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
>> type hinting for variable assignments, we've had quite a bit of syntactic
>> churn in the past few releases, and the rest of the ecosystem really hasn't
>> caught up on it all yet (and that's not just other implementations - it's
>> training material, online courses, etc, etc).
>>
>> If we're going to take such a step, now's also the time to do it, since
>> 3.8 feature development is only just getting under way, and if we did
>> decide to repeat the language moratorium, we could co-announce it with the
>> Python 3.7 release.
>>
>>
> Would it be reasonable to request a 10 year moratorium on making changes
> to the core Python language,
> and for the next 10 years only focus on things that do not require core
> language changes,
> such as improving/bugfixing existing libraries, writing new libraries,
> improving tooling, improving infrastructure (PyPI),
> improving performance, etc., etc.?
>
> There are still many companies still stuck on Python 2, so giving 10 years
> of breathing room
> for these companies to catch up to Python 3 core language, even past 2020
> would be very helpful.
>
> --
> Craig
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>


-- 
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Craig Rodrigues]

On Sun, May 6, 2018 at 7:35 PM Nick Coghlan  wrote:

>
> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
> language moratorium could be a very good idea. Between matrix
> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
> type hinting for variable assignments, we've had quite a bit of syntactic
> churn in the past few releases, and the rest of the ecosystem really hasn't
> caught up on it all yet (and that's not just other implementations - it's
> training material, online courses, etc, etc).
>
> If we're going to take such a step, now's also the time to do it, since
> 3.8 feature development is only just getting under way, and if we did
> decide to repeat the language moratorium, we could co-announce it with the
> Python 3.7 release.
>
>
Would it be reasonable to request a 10 year moratorium on making changes to
the core Python language,
and for the next 10 years only focus on things that do not require core
language changes,
such as improving/bugfixing existing libraries, writing new libraries,
improving tooling, improving infrastructure (PyPI),
improving performance, etc., etc.?

There are still many companies still stuck on Python 2, so giving 10 years
of breathing room
for these companies to catch up to Python 3 core language, even past 2020
would be very helpful.

--
Craig
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Glenn Linderman]

On 5/7/2018 7:59 AM, Eric Snow wrote:

On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan  wrote:

I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
language moratorium could be a very good idea.

Note that the PEP specifically applies to "syntax, semantics, and
built-ins".  Here's the full abstract [1]:

 This PEP proposes a temporary moratorium (suspension) of all changes to the
 Python language syntax, semantics, and built-ins for a period of
at least two
 years from the release of Python 3.1. In particular, the moratorium would
 include Python 3.2 (to be released 18-24 months after 3.1) but allow Python
 3.3 (assuming it is not released prematurely) to once again include 
language
 changes.

 This suspension of features is designed to allow non-CPython 
implementations
 to "catch up" to the core implementation of the language, help ease 
adoption
 of Python 3.x, and provide a more stable base for the community.

-eric

Here's my "lightning" response to a "lightning talk" about a moratorium:

So if other implementations didn't catch up during the last moratorium, 
either the moratorium then was lifted too soon, or the other 
implementations don't really want to catch up, or the thought that they 
should catch up was deemed less important than making forward progress 
with the language. Have any of those opinions changed?


While async is a big change that I personally haven't grasped, but which 
has little impact (a couple keywords) on code that doesn't use it, a new 
moratorium wouldn't impact it, and nothing else that is happening seems 
too much or too fast from my perspective.


Dan's original comment about language versus library is interesting, 
though. It is probably true that one should resist adding language where 
library suffices, but sometimes a lack of certain expressiveness in the 
language causes cumbersome implementations of library routines to 
achieve the goal.


f-strings and binding expressions are cases where (1) the functionality 
is certainly possible via library (2) there is a large amount of code 
that uses the functionality, and (3) said code is more cumbersome 
without the expressiveness of the newer syntax.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Lukasz Langa]

> On May 7, 2018, at 9:57 AM, Brett Cannon  wrote:
> 
> 
> 
> On Mon, 7 May 2018 at 09:55 Ivan Levkivskyi  > wrote:
> On 7 May 2018 at 17:32, Brett Cannon  > wrote:
> On Mon, 7 May 2018 at 08:18 João Santos  > wrote:
> Hi,
> 
> I would like to see this go even further and have a tick-tock approach to 
> python versions, i.e. adopt new syntax and other large changes on one version 
> (for example odd versions) and polish everything up in the next (even 
> versions).
> 
> [...], so I would advise we stick to the discussion on a moratorium [...]
> 
> 
> Btw the upcoming Language Summit may be a good opportunity for such 
> discussion.
> 
> If it's not already on the schedule for discussion then the best you are 
> going to get is a lightning talk to bring up the idea which will definitely 
> not enough time ;) . Otherwise the schedule is full and locked down at this 
> point.

FWIW I'm hearing the 3.8 release manager has a short talk related to this 
subject!

- Ł___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Brett Cannon]

On Mon, 7 May 2018 at 09:55 Ivan Levkivskyi  wrote:

> On 7 May 2018 at 17:32, Brett Cannon  wrote:
>
>> On Mon, 7 May 2018 at 08:18 João Santos  wrote:
>>
>>> Hi,
>>>
>>> I would like to see this go even further and have a tick-tock approach
>>> to python versions, i.e. adopt new syntax and other large changes on one
>>> version (for example odd versions) and polish everything up in the next
>>> (even versions).
>>>
>>
>> [...], so I would advise we stick to the discussion on a moratorium [...]
>>
>>
> Btw the upcoming Language Summit may be a good opportunity for such
> discussion.
>

If it's not already on the schedule for discussion then the best you are
going to get is a lightning talk to bring up the idea which will definitely
not enough time ;) . Otherwise the schedule is full and locked down at this
point.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Ivan Levkivskyi]

On 7 May 2018 at 17:32, Brett Cannon  wrote:

>
>
> On Mon, 7 May 2018 at 08:18 João Santos  wrote:
>
>> Hi,
>>
>> I would like to see this go even further and have a tick-tock approach to
>> python versions, i.e. adopt new syntax and other large changes on one
>> version (for example odd versions) and polish everything up in the next
>> (even versions).
>>
>
> [...], so I would advise we stick to the discussion on a moratorium [...]
>
>
Btw the upcoming Language Summit may be a good opportunity for such
discussion.

--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Brett Cannon]

On Mon, 7 May 2018 at 08:18 João Santos  wrote:

> Hi,
>
> I would like to see this go even further and have a tick-tock approach to
> python versions, i.e. adopt new syntax and other large changes on one
> version (for example odd versions) and polish everything up in the next
> (even versions).
>

That's basically an LTS release cycle and discussions of changing how we do
releases is a massive discussion that ultimately goes nowhere, so I would
advise we stick to the discussion on a moratorium before trying to change
how we release Python. :)

-Brett


>
> Best regards,
> João Santos
>
> On Mon, 7 May 2018 at 11:19 Ivan Levkivskyi  wrote:
>
>> On 7 May 2018 at 03:25, Nick Coghlan  wrote:
>>
>>> On 7 May 2018 at 11:30, Dan Stromberg  wrote:
>>>
 I'd very much like a live in a world where Jython and IronPython and
 MicroPython and Cython and Pyjamas can all catch up and implement
 Python 3.7, 3.8, and so forth.

>>>
>>> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP
>>> 3003 language moratorium could be a very good idea. Between matrix
>>> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
>>> type hinting for variable assignments, we've had quite a bit of syntactic
>>> churn in the past few releases, and the rest of the ecosystem really hasn't
>>> caught up on it all yet (and that's not just other implementations - it's
>>> training material, online courses, etc, etc).
>>>
>>> If we're going to take such a step, now's also the time to do it, since
>>> 3.8 feature development is only just getting under way, and if we did
>>> decide to repeat the language moratorium, we could co-announce it with the
>>> Python 3.7 release.
>>>
>>>
>> These are all god points. I think it will be a good idea to take a little
>> pause with syntactic additions and other "cognitively loaded" changes. On
>> the other hand, I think it is fine to work on performance improvements
>> (start-up time, import system etc.), internal APIs (like simplifying
>> start-up sequence and maybe even C API), and polishing corner
>> cases/simplifying existing constructs (like scoping in comprehensions that
>> many people find confusing).
>>
>> IOW, I think the PEP should describe precisely what is OK, and what is
>> not OK during the moratorium.
>>
>> --
>> Ivan
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu
>>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[João Santos]

Hi,

I would like to see this go even further and have a tick-tock approach to
python versions, i.e. adopt new syntax and other large changes on one
version (for example odd versions) and polish everything up in the next
(even versions).

Best regards,
João Santos

On Mon, 7 May 2018 at 11:19 Ivan Levkivskyi  wrote:

> On 7 May 2018 at 03:25, Nick Coghlan  wrote:
>
>> On 7 May 2018 at 11:30, Dan Stromberg  wrote:
>>
>>> I'd very much like a live in a world where Jython and IronPython and
>>> MicroPython and Cython and Pyjamas can all catch up and implement
>>> Python 3.7, 3.8, and so forth.
>>>
>>
>> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
>> language moratorium could be a very good idea. Between matrix
>> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
>> type hinting for variable assignments, we've had quite a bit of syntactic
>> churn in the past few releases, and the rest of the ecosystem really hasn't
>> caught up on it all yet (and that's not just other implementations - it's
>> training material, online courses, etc, etc).
>>
>> If we're going to take such a step, now's also the time to do it, since
>> 3.8 feature development is only just getting under way, and if we did
>> decide to repeat the language moratorium, we could co-announce it with the
>> Python 3.7 release.
>>
>>
> These are all god points. I think it will be a good idea to take a little
> pause with syntactic additions and other "cognitively loaded" changes. On
> the other hand, I think it is fine to work on performance improvements
> (start-up time, import system etc.), internal APIs (like simplifying
> start-up sequence and maybe even C API), and polishing corner
> cases/simplifying existing constructs (like scoping in comprehensions that
> many people find confusing).
>
> IOW, I think the PEP should describe precisely what is OK, and what is not
> OK during the moratorium.
>
> --
> Ivan
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jmcs%40jsantos.eu
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Eric Snow]

On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan  wrote:
> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
> language moratorium could be a very good idea.

Note that the PEP specifically applies to "syntax, semantics, and
built-ins".  Here's the full abstract [1]:

This PEP proposes a temporary moratorium (suspension) of all changes to the
Python language syntax, semantics, and built-ins for a period of
at least two
years from the release of Python 3.1. In particular, the moratorium would
include Python 3.2 (to be released 18-24 months after 3.1) but allow Python
3.3 (assuming it is not released prematurely) to once again include language
changes.

This suspension of features is designed to allow non-CPython implementations
to "catch up" to the core implementation of the language, help ease adoption
of Python 3.x, and provide a more stable base for the community.

-eric


[1] https://www.python.org/dev/peps/pep-3003/#abstract
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Serhiy Storchaka]

07.05.18 16:50, Joao S. O. Bueno пише:

May it is important to note that
Python 3.7 already has very little syntactic changes.
Actually, there are no new syntac changes with PEP 563 -
(Postponed Evaluation of Annotations) being maybe
the only change to existing behavior, and PEP 562 as new
"non-library-dependent"  feature, even though no new syntax is
added. (contextvars - PEP 567 - is a big change, but is constrained to
a new stdlib module).


It looks to me that Python 3.7 may cause the largest breakage since 3.2 
because of "async". It is pretty popular name for arguments, attributes 
and methods. Many third-party projects needed to fix this now (despites 
it was deprecated since 3.5). Many third-party projects depends on 
libraries which needed the "async" fix for 3.7.


But in general this breakage is very small. It just looks larger than in 
previous versions.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Joao S. O. Bueno]

May it is important to note that
Python 3.7 already has very little syntactic changes.
Actually, there are no new syntac changes with PEP 563 -
(Postponed Evaluation of Annotations) being maybe
the only change to existing behavior, and PEP 562 as new
"non-library-dependent"  feature, even though no new syntax is
added. (contextvars - PEP 567 - is a big change, but is constrained to
a new stdlib module).

On the other hand, one of the hottest topics being discussed now
 - PEP 572 - would be quite a change that would violate such a
moratorium. What would happen if we wd'd take such a  moratorium now?
 Have Python with no real syntactic changes since f-strings up to version
3.9 (~4.5 years after 3.6)? Allow just whatever is already being discussed
 - introducing a major change (local assignments) in 3.8, but just bar
others because people did not think of then before this moratorium
 was proposed?

Maybe simply there is just no need for such a moratorium mechanism,
and the natural barriers for new features can work to keep
things in manageable pace, as we can see by the release getting
 ready right now.

best regards,

  js
 -><-

On 7 May 2018 at 10:20, Serhiy Storchaka  wrote:
> 07.05.18 14:19, Nick Coghlan пише:
>>
>> And as the current python-ideas discussion about accessing paths relative
>> to __file__ shows,
>
>
> I can't believe this is discussed seriously. Forgot about the Python 2
> legacy, just use importlib.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Serhiy Storchaka]

07.05.18 14:19, Nick Coghlan пише:
And as the current python-ideas discussion about accessing paths 
relative to __file__ shows,


I can't believe this is discussed seriously. Forgot about the Python 2 
legacy, just use importlib.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Nick Coghlan]

On 7 May 2018 at 19:17, Ivan Levkivskyi  wrote:

> These are all god points. I think it will be a good idea to take a little
> pause with syntactic additions and other "cognitively loaded" changes. On
> the other hand, I think it is fine to work on performance improvements
> (start-up time, import system etc.), internal APIs (like simplifying
> start-up sequence and maybe even C API), and polishing corner
> cases/simplifying existing constructs (like scoping in comprehensions that
> many people find confusing).
>
> IOW, I think the PEP should describe precisely what is OK, and what is not
> OK during the moratorium.
>

Aye, for folks that haven't read it before,
https://www.python.org/dev/peps/pep-3003/#details is worth a look as to the
specifics of what a language moratorium entails.

While only 3.2 was specifically covered by the moratorium, from 3.2 through
to 3.4, the only language level changes we made were to allow "yield from
x" as a coroutine-friendly alternative to "for x in iterable: yield x", and
to reinstate support for the "u" prefix on strings. The main builtin
changes in that period were to rework the exception hierarchy to make it
more descriptive of what *caused* an error, rather than where the error was
raised, and those were deliberately designed to be almost entirely
backwards compatible.

Since that last period of calm, 3.5 and 3.6 both introduced a broad
selection of syntax changes, and even 3.7 has introduced a new __future__
statement to change the way annotations are handled. And as the current
python-ideas discussion about accessing paths relative to __file__ shows,
even core devs (i.e. me) are still digesting the full implications that
pathlib and the os.fspath protocol may have for the recommendations that we
should be giving to new (and existing!) developers that don't need to worry
about Python 2.7 compatibility.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Ivan Levkivskyi]

On 7 May 2018 at 03:25, Nick Coghlan  wrote:

> On 7 May 2018 at 11:30, Dan Stromberg  wrote:
>
>> I'd very much like a live in a world where Jython and IronPython and
>> MicroPython and Cython and Pyjamas can all catch up and implement
>> Python 3.7, 3.8, and so forth.
>>
>
> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
> language moratorium could be a very good idea. Between matrix
> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
> type hinting for variable assignments, we've had quite a bit of syntactic
> churn in the past few releases, and the rest of the ecosystem really hasn't
> caught up on it all yet (and that's not just other implementations - it's
> training material, online courses, etc, etc).
>
> If we're going to take such a step, now's also the time to do it, since
> 3.8 feature development is only just getting under way, and if we did
> decide to repeat the language moratorium, we could co-announce it with the
> Python 3.7 release.
>
>
These are all god points. I think it will be a good idea to take a little
pause with syntactic additions and other "cognitively loaded" changes. On
the other hand, I think it is fine to work on performance improvements
(start-up time, import system etc.), internal APIs (like simplifying
start-up sequence and maybe even C API), and polishing corner
cases/simplifying existing constructs (like scoping in comprehensions that
many people find confusing).

IOW, I think the PEP should describe precisely what is OK, and what is not
OK during the moratorium.

--
Ivan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Antoine Pitrou]

On Mon, 7 May 2018 12:25:46 +1000
Nick Coghlan  wrote:
> On 7 May 2018 at 11:30, Dan Stromberg  wrote:
> 
> > I'd very much like a live in a world where Jython and IronPython and
> > MicroPython and Cython and Pyjamas can all catch up and implement
> > Python 3.7, 3.8, and so forth.
> >  
> 
> I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
> language moratorium could be a very good idea. Between matrix
> multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
> type hinting for variable assignments, we've had quite a bit of syntactic
> churn in the past few releases, and the rest of the ecosystem really hasn't
> caught up on it all yet (and that's not just other implementations - it's
> training material, online courses, etc, etc).

Not to mention people themselves.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slow down...

[Nick Coghlan]

On 7 May 2018 at 11:30, Dan Stromberg  wrote:

> I'd very much like a live in a world where Jython and IronPython and
> MicroPython and Cython and Pyjamas can all catch up and implement
> Python 3.7, 3.8, and so forth.
>

I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
language moratorium could be a very good idea. Between matrix
multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
type hinting for variable assignments, we've had quite a bit of syntactic
churn in the past few releases, and the rest of the ecosystem really hasn't
caught up on it all yet (and that's not just other implementations - it's
training material, online courses, etc, etc).

If we're going to take such a step, now's also the time to do it, since 3.8
feature development is only just getting under way, and if we did decide to
repeat the language moratorium, we could co-announce it with the Python 3.7
release.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Slow down...

[Dan Stromberg]

When I think of why Python is so far ahead of Perl in language design,
I think it's simply that Python is the result of cautious design, and
Perl is the result of exuberant design.

I think Python is in danger of becoming a large language - which isn't
a good thing.

A great language, like Scheme or Python or even C, is a language that
has a small, very useful core, and large _libraries_.

I'd very much like a live in a world where Jython and IronPython and
MicroPython and Cython and Pyjamas can all catch up and implement
Python 3.7, 3.8, and so forth.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com