Re: [Python-Dev] A fast startup patch (was: Python startup time)

[Ryan Gonzalez]

On May 7, 2018 9:15:32 PM Steve Dower  wrote:

“the data shows that a focused change to address file system inefficiencies 
has the potential to broadly and transparently deliver benefit to users 
without affecting existing code or workflows.”


This is consistent with a Node.js experiment I heard about where they 
compiled an entire application in a single (HUGE!) .js file. Reading a 
single large file from disk is quicker than many small files on every 
significant file system I’m aware of. Is there benefit to supporting import 
of .tar files as we currently do .zip? Or perhaps having a special 
fast-path for uncompressed .zip files?


I kind of built something like this, though I haven't really put in the 
effort to make it overly usable yet:


https://github.com/kirbyfan64/bluesnow

(Bonus points to anyone who gets the character reference in the name, 
though I seriously doubt it.)


Main thing I noticed was that reading compiled .pyc files is far faster 
than uncompiled Python code, even if you eliminate the disk access. Kind of 
obvious in retrospect, but still something to note


However, there are more obstacles to this in the Python world than the JS 
world. C extensions have a heavier prevalence here, distribution is a bit 
weirder (sorry, even with Pipfiles), and JavaScript already has an entire 
ecosystem built around packing files together from the web world.




Top-posted from my Windows phone

From: Carl Shapiro
Sent: Monday, May 7, 2018 14:36
To: Nathaniel Smith
Cc: Nick Coghlan; Python Dev
Subject: Re: [Python-Dev] A fast startup patch (was: Python startup time)

On Fri, May 4, 2018 at 6:58 PM, Nathaniel Smith  wrote:
What are the obstacles to including "preloaded" objects in regular .pyc 
files, so that everyone can take advantage of this without rebuilding the 
interpreter?


The system we have developed can create a shared object file for each 
compiled Python file.  However, such a representation is not directly 
usable.  First, certain shared constants, such as interned strings, must be 
kept globally unique across object code files.  Second, some marshaled 
objects, such as the hashed collections, must be initialized with 
randomization state that is not available until after the hosting runtime 
has been initialized.


We are able to work around the first issue by generating a heap image with 
the transitive closure of all modules that will be loaded which allows us 
to easily maintain uniqueness guarantees.  We are able to work around the 
second issue with some unobservable changes to the affected data structures.

 
Based on our numbers, it appears there should be some hesitancy--at this 
time--to changing the format of compiled Python file for the sake of 
load-time performance.  In contrast, the data shows that a focused change 
to address file system inefficiencies has the potential to broadly and 
transparently deliver benefit to users without affecting existing code or 
workflows. 





--
___
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] A fast startup patch (was: Python startup time)

[Steve Dower]

“the data shows that a focused change to address file system inefficiencies has 
the potential to broadly and transparently deliver benefit to users without 
affecting existing code or workflows.”

This is consistent with a Node.js experiment I heard about where they compiled 
an entire application in a single (HUGE!) .js file. Reading a single large file 
from disk is quicker than many small files on every significant file system I’m 
aware of. Is there benefit to supporting import of .tar files as we currently 
do .zip? Or perhaps having a special fast-path for uncompressed .zip files?

Top-posted from my Windows phone

From: Carl Shapiro
Sent: Monday, May 7, 2018 14:36
To: Nathaniel Smith
Cc: Nick Coghlan; Python Dev
Subject: Re: [Python-Dev] A fast startup patch (was: Python startup time)

On Fri, May 4, 2018 at 6:58 PM, Nathaniel Smith  wrote:
What are the obstacles to including "preloaded" objects in regular .pyc files, 
so that everyone can take advantage of this without rebuilding the interpreter?

The system we have developed can create a shared object file for each compiled 
Python file.  However, such a representation is not directly usable.  First, 
certain shared constants, such as interned strings, must be kept globally 
unique across object code files.  Second, some marshaled objects, such as the 
hashed collections, must be initialized with randomization state that is not 
available until after the hosting runtime has been initialized.

We are able to work around the first issue by generating a heap image with the 
transitive closure of all modules that will be loaded which allows us to easily 
maintain uniqueness guarantees.  We are able to work around the second issue 
with some unobservable changes to the affected data structures.
 
Based on our numbers, it appears there should be some hesitancy--at this 
time--to changing the format of compiled Python file for the sake of load-time 
performance.  In contrast, the data shows that a focused change to address file 
system inefficiencies has the potential to broadly and transparently deliver 
benefit to users without affecting existing code or workflows. 

___
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  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] A fast startup patch (was: Python startup time)

[Carl Shapiro]

On Fri, May 4, 2018 at 6:58 PM, Nathaniel Smith  wrote:

> What are the obstacles to including "preloaded" objects in regular .pyc
> files, so that everyone can take advantage of this without rebuilding the
> interpreter?
>

The system we have developed can create a shared object file for each
compiled Python file.  However, such a representation is not directly
usable.  First, certain shared constants, such as interned strings, must be
kept globally unique across object code files.  Second, some marshaled
objects, such as the hashed collections, must be initialized with
randomization state that is not available until after the hosting runtime
has been initialized.

We are able to work around the first issue by generating a heap image with
the transitive closure of all modules that will be loaded which allows us
to easily maintain uniqueness guarantees.  We are able to work around the
second issue with some unobservable changes to the affected data structures.

Based on our numbers, it appears there should be some hesitancy--at this
time--to changing the format of compiled Python file for the sake of
load-time performance.  In contrast, the data shows that a focused change
to address file system inefficiencies has the potential to broadly and
transparently deliver benefit to users without affecting existing code or
workflows.
___
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] Python startup time

[Neil Schemenauer]

On 2018-05-03, Lukasz Langa wrote:
> > On May 2, 2018, at 8:57 PM, INADA Naoki  wrote:
> > * Add lazy compiling API or flag in `re` module.  The pattern is compiled
> > when first used.
> 
> How about go the other way and allow compiling at Python
> *compile*-time? That would actually make things faster instead of
> just moving the time spent around.

Lisp has a special form 'eval-when'.  It can be used to cause
evaluation of the body expression at compile time.

In Carl's "A fast startup patch" post, he talks about getting rid of
the unmarshal step and storing objects in the heap segment of the
executable.  Those would be the objects necessary to evaluate code.
The marshal module has a limited number of types that it handle.
I believe they are: bool, bytes, code objects, complex, Ellipsis
float, frozenset, int, None, tuple and str.

If the same mechanism could handle more types, rather than storing
the code to be evaluated, we could store the objects created after
evaluation of the top-level module body.  Or, have a mechanism to
mark which code should be evaluated at compile time (much like the
eval-when form).

For the re.compile example, the compiled regex could be what is
stored after compiling the Python module (i.e. the re.compile gets
run at compile time).  The objects created by re.compile (e.g.
SRE_Pattern) would have to be something that the heap dumper could
handle.

Traditionally, Python has had the model "there is only runtime".
So, starting to do things at compile time complicates that model.

Regards,

  Neil
___
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

[Python-Dev] static linking Python

[Antoine Pitrou]

On Fri, 04 May 2018 00:21:54 +
Ray Donnelly  wrote:
> 
> Now that Python 3.7 is around the corner we have a chance to re-evaluate
> this decision. We have received no binary compat. bugs whatsoever due to
> this change (we got a few bugs where people used python-config incorrectly
> either directly or via swig or CMake), were we just lucky?

As a sidenote, it seems there may be issues when static linking against
Python to embed it:
https://bugs.python.org/issue33438

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

[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