Re: [Python-Dev] Speeding up CPython 5-10%

[Meador Inge]

On Sun, May 15, 2016 at 2:23 AM, Cesare Di Mauro 
wrote:


> Just one thing that comes to my mind: is the stack depth calculation
> routine changed? It was suboptimal, and calculating a better number
> decreases stack allocation, and increases the frame usage.
>

This is still a problem and came up again recently:

http://bugs.python.org/issue26549

-- Meador
___
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] File system path PEP, 3rd draft

[Brett Cannon]

Recent discussions have been about type hints which are orthogonal to the
PEP, so things have seemed to have reached a steady state.

Was there anything else that needed clarification, Guido, or are you ready
to pronounce? Or did you want to wait until the language summit? Or did you
want to assign a BDFL delegate?

On Fri, 13 May 2016 at 11:37 Brett Cannon  wrote:

> Biggest changes since the second draft:
>
>1. Resolve __fspath__() from the type, not the instance (for Guido)
>2. Updated the TypeError messages to say "os.PathLike object" instead
>of "path object" (implicitly for Steven)
>3. TODO item to define "path-like" in the glossary (for Steven)
>4. Various more things added to Rejected Ideas
>5. Added Koos as a co-author (for Koos :)
>
> --
> PEP: NNN
> Title: Adding a file system path protocol
> Version: $Revision$
> Last-Modified: $Date$
> Author: Brett Cannon ,
> Koos Zevenhoven 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 11-May-2016
> Post-History: 11-May-2016,
>   12-May-2016,
>   13-May-2016
>
>
> Abstract
> 
>
> This PEP proposes a protocol for classes which represent a file system
> path to be able to provide a ``str`` or ``bytes`` representation.
> Changes to Python's standard library are also proposed to utilize this
> protocol where appropriate to facilitate the use of path objects where
> historically only ``str`` and/or ``bytes`` file system paths are
> accepted. The goal is to facilitate the migration of users towards
> rich path objects while providing an easy way to work with code
> expecting ``str`` or ``bytes``.
>
>
> Rationale
> =
>
> Historically in Python, file system paths have been represented as
> strings or bytes. This choice of representation has stemmed from C's
> own decision to represent file system paths as
> ``const char *`` [#libc-open]_. While that is a totally serviceable
> format to use for file system paths, it's not necessarily optimal. At
> issue is the fact that while all file system paths can be represented
> as strings or bytes, not all strings or bytes represent a file system
> path. This can lead to issues where any e.g. string duck-types to a
> file system path whether it actually represents a path or not.
>
> To help elevate the representation of file system paths from their
> representation as strings and bytes to a richer object representation,
> the pathlib module [#pathlib]_ was provisionally introduced in
> Python 3.4 through PEP 428. While considered by some as an improvement
> over strings and bytes for file system paths, it has suffered from a
> lack of adoption. Typically the key issue listed for the low adoption
> rate has been the lack of support in the standard library. This lack
> of support required users of pathlib to manually convert path objects
> to strings by calling ``str(path)`` which many found error-prone.
>
> One issue in converting path objects to strings comes from
> the fact that the only generic way to get a string representation of
> the path was to pass the object to ``str()``. This can pose a
> problem when done blindly as nearly all Python objects have some
> string representation whether they are a path or not, e.g.
> ``str(None)`` will give a result that
> ``builtins.open()`` [#builtins-open]_ will happily use to create a new
> file.
>
> Exacerbating this whole situation is the
> ``DirEntry`` object [#os-direntry]_. While path objects have a
> representation that can be extracted using ``str()``, ``DirEntry``
> objects expose a ``path`` attribute instead. Having no common
> interface between path objects, ``DirEntry``, and any other
> third-party path library has become an issue. A solution that allows
> any path-representing object to declare that it is a path and a way
> to extract a low-level representation that all path objects could
> support is desired.
>
> This PEP then proposes to introduce a new protocol to be followed by
> objects which represent file system paths. Providing a protocol allows
> for explicit signaling of what objects represent file system paths as
> well as a way to extract a lower-level representation that can be used
> with older APIs which only support strings or bytes.
>
> Discussions regarding path objects that led to this PEP can be found
> in multiple threads on the python-ideas mailing list archive
> [#python-ideas-archive]_ for the months of March and April 2016 and on
> the python-dev mailing list archives [#python-dev-archive]_ during
> April 2016.
>
>
> Proposal
> 
>
> This proposal is split into two parts. One part is the proposal of a
> protocol for objects to declare and provide support for exposing a
> file system path representation. The other part deals with changes to
> Python's standard library to support the new protocol. These changes
> will also lead to the pathlib module dropping its provisional status.
>
> Protocol
> 
>
> The following abstrac

Re: [Python-Dev] File system path PEP, 3rd draft

[Guido van Rossum]

Once you assign yourself a PEP number I'll do one more pass and then I
expect to accept it -- the draft looks good to me!

On Mon, May 16, 2016 at 1:00 PM, Brett Cannon  wrote:

> Recent discussions have been about type hints which are orthogonal to the
> PEP, so things have seemed to have reached a steady state.
>
> Was there anything else that needed clarification, Guido, or are you ready
> to pronounce? Or did you want to wait until the language summit? Or did you
> want to assign a BDFL delegate?
>
>
> On Fri, 13 May 2016 at 11:37 Brett Cannon  wrote:
>
>> Biggest changes since the second draft:
>>
>>1. Resolve __fspath__() from the type, not the instance (for Guido)
>>2. Updated the TypeError messages to say "os.PathLike object" instead
>>of "path object" (implicitly for Steven)
>>3. TODO item to define "path-like" in the glossary (for Steven)
>>4. Various more things added to Rejected Ideas
>>5. Added Koos as a co-author (for Koos :)
>>
>> --
>> PEP: NNN
>> Title: Adding a file system path protocol
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Brett Cannon ,
>> Koos Zevenhoven 
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 11-May-2016
>> Post-History: 11-May-2016,
>>   12-May-2016,
>>   13-May-2016
>>
>>
>> Abstract
>> 
>>
>> This PEP proposes a protocol for classes which represent a file system
>> path to be able to provide a ``str`` or ``bytes`` representation.
>> Changes to Python's standard library are also proposed to utilize this
>> protocol where appropriate to facilitate the use of path objects where
>> historically only ``str`` and/or ``bytes`` file system paths are
>> accepted. The goal is to facilitate the migration of users towards
>> rich path objects while providing an easy way to work with code
>> expecting ``str`` or ``bytes``.
>>
>>
>> Rationale
>> =
>>
>> Historically in Python, file system paths have been represented as
>> strings or bytes. This choice of representation has stemmed from C's
>> own decision to represent file system paths as
>> ``const char *`` [#libc-open]_. While that is a totally serviceable
>> format to use for file system paths, it's not necessarily optimal. At
>> issue is the fact that while all file system paths can be represented
>> as strings or bytes, not all strings or bytes represent a file system
>> path. This can lead to issues where any e.g. string duck-types to a
>> file system path whether it actually represents a path or not.
>>
>> To help elevate the representation of file system paths from their
>> representation as strings and bytes to a richer object representation,
>> the pathlib module [#pathlib]_ was provisionally introduced in
>> Python 3.4 through PEP 428. While considered by some as an improvement
>> over strings and bytes for file system paths, it has suffered from a
>> lack of adoption. Typically the key issue listed for the low adoption
>> rate has been the lack of support in the standard library. This lack
>> of support required users of pathlib to manually convert path objects
>> to strings by calling ``str(path)`` which many found error-prone.
>>
>> One issue in converting path objects to strings comes from
>> the fact that the only generic way to get a string representation of
>> the path was to pass the object to ``str()``. This can pose a
>> problem when done blindly as nearly all Python objects have some
>> string representation whether they are a path or not, e.g.
>> ``str(None)`` will give a result that
>> ``builtins.open()`` [#builtins-open]_ will happily use to create a new
>> file.
>>
>> Exacerbating this whole situation is the
>> ``DirEntry`` object [#os-direntry]_. While path objects have a
>> representation that can be extracted using ``str()``, ``DirEntry``
>> objects expose a ``path`` attribute instead. Having no common
>> interface between path objects, ``DirEntry``, and any other
>> third-party path library has become an issue. A solution that allows
>> any path-representing object to declare that it is a path and a way
>> to extract a low-level representation that all path objects could
>> support is desired.
>>
>> This PEP then proposes to introduce a new protocol to be followed by
>> objects which represent file system paths. Providing a protocol allows
>> for explicit signaling of what objects represent file system paths as
>> well as a way to extract a lower-level representation that can be used
>> with older APIs which only support strings or bytes.
>>
>> Discussions regarding path objects that led to this PEP can be found
>> in multiple threads on the python-ideas mailing list archive
>> [#python-ideas-archive]_ for the months of March and April 2016 and on
>> the python-dev mailing list archives [#python-dev-archive]_ during
>> April 2016.
>>
>>
>> Proposal
>> 
>>
>> This proposal is split into two parts. One part is the proposal of a
>> protocol for objects to declare and pr

Re: [Python-Dev] File system path PEP, 3rd draft

[Brett Cannon]

On Mon, 16 May 2016 at 13:12 Guido van Rossum  wrote:

> Once you assign yourself a PEP number I'll do one more pass and then I
> expect to accept it -- the draft looks good to me!
>

Done: https://hg.python.org/peps/rev/b41cb718054a


>
> On Mon, May 16, 2016 at 1:00 PM, Brett Cannon  wrote:
>
>> Recent discussions have been about type hints which are orthogonal to the
>> PEP, so things have seemed to have reached a steady state.
>>
>> Was there anything else that needed clarification, Guido, or are you
>> ready to pronounce? Or did you want to wait until the language summit? Or
>> did you want to assign a BDFL delegate?
>>
>>
>> On Fri, 13 May 2016 at 11:37 Brett Cannon  wrote:
>>
>>> Biggest changes since the second draft:
>>>
>>>1. Resolve __fspath__() from the type, not the instance (for Guido)
>>>2. Updated the TypeError messages to say "os.PathLike object"
>>>instead of "path object" (implicitly for Steven)
>>>3. TODO item to define "path-like" in the glossary (for Steven)
>>>4. Various more things added to Rejected Ideas
>>>5. Added Koos as a co-author (for Koos :)
>>>
>>> --
>>> PEP: NNN
>>> Title: Adding a file system path protocol
>>> Version: $Revision$
>>> Last-Modified: $Date$
>>> Author: Brett Cannon ,
>>> Koos Zevenhoven 
>>> Status: Draft
>>> Type: Standards Track
>>> Content-Type: text/x-rst
>>> Created: 11-May-2016
>>> Post-History: 11-May-2016,
>>>   12-May-2016,
>>>   13-May-2016
>>>
>>>
>>> Abstract
>>> 
>>>
>>> This PEP proposes a protocol for classes which represent a file system
>>> path to be able to provide a ``str`` or ``bytes`` representation.
>>> Changes to Python's standard library are also proposed to utilize this
>>> protocol where appropriate to facilitate the use of path objects where
>>> historically only ``str`` and/or ``bytes`` file system paths are
>>> accepted. The goal is to facilitate the migration of users towards
>>> rich path objects while providing an easy way to work with code
>>> expecting ``str`` or ``bytes``.
>>>
>>>
>>> Rationale
>>> =
>>>
>>> Historically in Python, file system paths have been represented as
>>> strings or bytes. This choice of representation has stemmed from C's
>>> own decision to represent file system paths as
>>> ``const char *`` [#libc-open]_. While that is a totally serviceable
>>> format to use for file system paths, it's not necessarily optimal. At
>>> issue is the fact that while all file system paths can be represented
>>> as strings or bytes, not all strings or bytes represent a file system
>>> path. This can lead to issues where any e.g. string duck-types to a
>>> file system path whether it actually represents a path or not.
>>>
>>> To help elevate the representation of file system paths from their
>>> representation as strings and bytes to a richer object representation,
>>> the pathlib module [#pathlib]_ was provisionally introduced in
>>> Python 3.4 through PEP 428. While considered by some as an improvement
>>> over strings and bytes for file system paths, it has suffered from a
>>> lack of adoption. Typically the key issue listed for the low adoption
>>> rate has been the lack of support in the standard library. This lack
>>> of support required users of pathlib to manually convert path objects
>>> to strings by calling ``str(path)`` which many found error-prone.
>>>
>>> One issue in converting path objects to strings comes from
>>> the fact that the only generic way to get a string representation of
>>> the path was to pass the object to ``str()``. This can pose a
>>> problem when done blindly as nearly all Python objects have some
>>> string representation whether they are a path or not, e.g.
>>> ``str(None)`` will give a result that
>>> ``builtins.open()`` [#builtins-open]_ will happily use to create a new
>>> file.
>>>
>>> Exacerbating this whole situation is the
>>> ``DirEntry`` object [#os-direntry]_. While path objects have a
>>> representation that can be extracted using ``str()``, ``DirEntry``
>>> objects expose a ``path`` attribute instead. Having no common
>>> interface between path objects, ``DirEntry``, and any other
>>> third-party path library has become an issue. A solution that allows
>>> any path-representing object to declare that it is a path and a way
>>> to extract a low-level representation that all path objects could
>>> support is desired.
>>>
>>> This PEP then proposes to introduce a new protocol to be followed by
>>> objects which represent file system paths. Providing a protocol allows
>>> for explicit signaling of what objects represent file system paths as
>>> well as a way to extract a lower-level representation that can be used
>>> with older APIs which only support strings or bytes.
>>>
>>> Discussions regarding path objects that led to this PEP can be found
>>> in multiple threads on the python-ideas mailing list archive
>>> [#python-ideas-archive]_ for the months of March and April 2016 and on
>>> the python

Re: [Python-Dev] File system path PEP, 3rd draft

[Guido van Rossum]

For those following along on the list, it's PEP 519:
https://www.python.org/dev/peps/pep-0519/

I've read it once more and found nothing worth bickering about, so I am
hereby approving PEP 519. Thanks Brett and Koos for getting this one over
the finish line, and congrats! It's been quite an effort (I personally did
not have the patience to keep up with the thread...).



On Mon, May 16, 2016 at 1:26 PM, Brett Cannon  wrote:

>
>
> On Mon, 16 May 2016 at 13:12 Guido van Rossum  wrote:
>
>> Once you assign yourself a PEP number I'll do one more pass and then I
>> expect to accept it -- the draft looks good to me!
>>
>
> Done: https://hg.python.org/peps/rev/b41cb718054a
>
>
>>
>> On Mon, May 16, 2016 at 1:00 PM, Brett Cannon  wrote:
>>
>>> Recent discussions have been about type hints which are orthogonal to
>>> the PEP, so things have seemed to have reached a steady state.
>>>
>>> Was there anything else that needed clarification, Guido, or are you
>>> ready to pronounce? Or did you want to wait until the language summit? Or
>>> did you want to assign a BDFL delegate?
>>>
>>>
>>> On Fri, 13 May 2016 at 11:37 Brett Cannon  wrote:
>>>
 Biggest changes since the second draft:

1. Resolve __fspath__() from the type, not the instance (for Guido)
2. Updated the TypeError messages to say "os.PathLike object"
instead of "path object" (implicitly for Steven)
3. TODO item to define "path-like" in the glossary (for Steven)
4. Various more things added to Rejected Ideas
5. Added Koos as a co-author (for Koos :)

 --
 PEP: NNN
 Title: Adding a file system path protocol
 Version: $Revision$
 Last-Modified: $Date$
 Author: Brett Cannon ,
 Koos Zevenhoven 
 Status: Draft
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 11-May-2016
 Post-History: 11-May-2016,
   12-May-2016,
   13-May-2016


 Abstract
 

 This PEP proposes a protocol for classes which represent a file system
 path to be able to provide a ``str`` or ``bytes`` representation.
 Changes to Python's standard library are also proposed to utilize this
 protocol where appropriate to facilitate the use of path objects where
 historically only ``str`` and/or ``bytes`` file system paths are
 accepted. The goal is to facilitate the migration of users towards
 rich path objects while providing an easy way to work with code
 expecting ``str`` or ``bytes``.


 Rationale
 =

 Historically in Python, file system paths have been represented as
 strings or bytes. This choice of representation has stemmed from C's
 own decision to represent file system paths as
 ``const char *`` [#libc-open]_. While that is a totally serviceable
 format to use for file system paths, it's not necessarily optimal. At
 issue is the fact that while all file system paths can be represented
 as strings or bytes, not all strings or bytes represent a file system
 path. This can lead to issues where any e.g. string duck-types to a
 file system path whether it actually represents a path or not.

 To help elevate the representation of file system paths from their
 representation as strings and bytes to a richer object representation,
 the pathlib module [#pathlib]_ was provisionally introduced in
 Python 3.4 through PEP 428. While considered by some as an improvement
 over strings and bytes for file system paths, it has suffered from a
 lack of adoption. Typically the key issue listed for the low adoption
 rate has been the lack of support in the standard library. This lack
 of support required users of pathlib to manually convert path objects
 to strings by calling ``str(path)`` which many found error-prone.

 One issue in converting path objects to strings comes from
 the fact that the only generic way to get a string representation of
 the path was to pass the object to ``str()``. This can pose a
 problem when done blindly as nearly all Python objects have some
 string representation whether they are a path or not, e.g.
 ``str(None)`` will give a result that
 ``builtins.open()`` [#builtins-open]_ will happily use to create a new
 file.

 Exacerbating this whole situation is the
 ``DirEntry`` object [#os-direntry]_. While path objects have a
 representation that can be extracted using ``str()``, ``DirEntry``
 objects expose a ``path`` attribute instead. Having no common
 interface between path objects, ``DirEntry``, and any other
 third-party path library has become an issue. A solution that allows
 any path-representing object to declare that it is a path and a way
 to extract a low-level representation that all path objects could
 support is desired.

 This PEP then proposes to introduce a new p

Re: [Python-Dev] File system path PEP, 3rd draft

[Brett Cannon]

On Mon, 16 May 2016 at 14:03 Guido van Rossum  wrote:

> For those following along on the list, it's PEP 519:
> https://www.python.org/dev/peps/pep-0519/
>
> I've read it once more and found nothing worth bickering about, so I am
> hereby approving PEP 519. Thanks Brett and Koos for getting this one over
> the finish line, and congrats! It's been quite an effort (I personally did
> not have the patience to keep up with the thread...).
>

PEP 519 is now marked as accepted! Two PEPs accepted in one day (Nick
approved 518 earlier)!

If pathlib doesn't get updated in 3.4, 3.5, and 3.6 before PyCon it will be
the first thing I do at the sprints so that it isn't an issue for the 3.5.2
release.

-Brett


>
>
>
> On Mon, May 16, 2016 at 1:26 PM, Brett Cannon  wrote:
>
>>
>>
>> On Mon, 16 May 2016 at 13:12 Guido van Rossum  wrote:
>>
>>> Once you assign yourself a PEP number I'll do one more pass and then I
>>> expect to accept it -- the draft looks good to me!
>>>
>>
>> Done: https://hg.python.org/peps/rev/b41cb718054a
>>
>>
>>>
>>> On Mon, May 16, 2016 at 1:00 PM, Brett Cannon  wrote:
>>>
 Recent discussions have been about type hints which are orthogonal to
 the PEP, so things have seemed to have reached a steady state.

 Was there anything else that needed clarification, Guido, or are you
 ready to pronounce? Or did you want to wait until the language summit? Or
 did you want to assign a BDFL delegate?


 On Fri, 13 May 2016 at 11:37 Brett Cannon  wrote:

> Biggest changes since the second draft:
>
>1. Resolve __fspath__() from the type, not the instance (for Guido)
>2. Updated the TypeError messages to say "os.PathLike object"
>instead of "path object" (implicitly for Steven)
>3. TODO item to define "path-like" in the glossary (for Steven)
>4. Various more things added to Rejected Ideas
>5. Added Koos as a co-author (for Koos :)
>
> --
> PEP: NNN
> Title: Adding a file system path protocol
> Version: $Revision$
> Last-Modified: $Date$
> Author: Brett Cannon ,
> Koos Zevenhoven 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 11-May-2016
> Post-History: 11-May-2016,
>   12-May-2016,
>   13-May-2016
>
>
> Abstract
> 
>
> This PEP proposes a protocol for classes which represent a file system
> path to be able to provide a ``str`` or ``bytes`` representation.
> Changes to Python's standard library are also proposed to utilize this
> protocol where appropriate to facilitate the use of path objects where
> historically only ``str`` and/or ``bytes`` file system paths are
> accepted. The goal is to facilitate the migration of users towards
> rich path objects while providing an easy way to work with code
> expecting ``str`` or ``bytes``.
>
>
> Rationale
> =
>
> Historically in Python, file system paths have been represented as
> strings or bytes. This choice of representation has stemmed from C's
> own decision to represent file system paths as
> ``const char *`` [#libc-open]_. While that is a totally serviceable
> format to use for file system paths, it's not necessarily optimal. At
> issue is the fact that while all file system paths can be represented
> as strings or bytes, not all strings or bytes represent a file system
> path. This can lead to issues where any e.g. string duck-types to a
> file system path whether it actually represents a path or not.
>
> To help elevate the representation of file system paths from their
> representation as strings and bytes to a richer object representation,
> the pathlib module [#pathlib]_ was provisionally introduced in
> Python 3.4 through PEP 428. While considered by some as an improvement
> over strings and bytes for file system paths, it has suffered from a
> lack of adoption. Typically the key issue listed for the low adoption
> rate has been the lack of support in the standard library. This lack
> of support required users of pathlib to manually convert path objects
> to strings by calling ``str(path)`` which many found error-prone.
>
> One issue in converting path objects to strings comes from
> the fact that the only generic way to get a string representation of
> the path was to pass the object to ``str()``. This can pose a
> problem when done blindly as nearly all Python objects have some
> string representation whether they are a path or not, e.g.
> ``str(None)`` will give a result that
> ``builtins.open()`` [#builtins-open]_ will happily use to create a new
> file.
>
> Exacerbating this whole situation is the
> ``DirEntry`` object [#os-direntry]_. While path objects have a
> representation that can be extracted using ``str()``, ``

Re: [Python-Dev] File system path PEP, 3rd draft

[Ethan Furman]

On 05/16/2016 02:32 PM, Brett Cannon wrote:


PEP 519 is now marked as accepted! Two PEPs accepted in one day (Nick
approved 518 earlier)!


Excellent!  :)


If pathlib doesn't get updated in 3.4, 3.5, and 3.6 before PyCon it will
be the first thing I do at the sprints so that it isn't an issue for the
3.5.2 release.


Isn't 3.4 now in security-fix mode?

--
~Ethan~

___
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] File system path PEP, 3rd draft

[Brett Cannon]

On Mon, May 16, 2016, 19:02 Ethan Furman  wrote:

> On 05/16/2016 02:32 PM, Brett Cannon wrote:
>
> > PEP 519 is now marked as accepted! Two PEPs accepted in one day (Nick
> > approved 518 earlier)!
>
> Excellent!  :)
>
> > If pathlib doesn't get updated in 3.4, 3.5, and 3.6 before PyCon it will
> > be the first thing I do at the sprints so that it isn't an issue for the
> > 3.5.2 release.
>
> Isn't 3.4 now in security-fix mode?
>

Yes, but because of pathlib's provisional status, Guido backported the path
attribute from 3.4 forward.

-brett


> --
> ~Ethan~
>
> ___
> 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] Speeding up CPython 5-10%

[Cesare Di Mauro]

2016-05-16 17:55 GMT+02:00 Meador Inge :

> On Sun, May 15, 2016 at 2:23 AM, Cesare Di Mauro <
> cesare.di.ma...@gmail.com> wrote:
>
>
>> Just one thing that comes to my mind: is the stack depth calculation
>> routine changed? It was suboptimal, and calculating a better number
>> decreases stack allocation, and increases the frame usage.
>>
>
> This is still a problem and came up again recently:
>
> http://bugs.python.org/issue26549
>
> -- Meador
>

I saw the last two comments of the issues: this is what I was talking about
(in particular the issue opened by Armin applies).

However there's another case where the situation is even worse.

Let me show a small reproducer:

def test(self):
for i in range(self.count):
with self: pass

The stack size reported by Python 2.7.11:
>>> test.__code__.co_stacksize
6

Adding another with statement:
>>> test.__code__.co_stacksize
7

But unfortunately with Python 3.5.1 the problematic is much worse:

>>> test.__code__.co_stacksize
10

>>> test.__code__.co_stacksize
17

Here the situation is exacerbated by the fact that the WITH_CLEANUP
instruction of Python 2.x was split into two (WITH_CLEANUP_START and
WITH_CLEANUP_FINISH) in some Python 3 release.

I don't know why two different instructions were introduced, but IMO it's
better to have one instruction which handles all code finalization of the
with statement, at least in this case. If there are other scenarios where
two different instructions are needed, then ad-hoc instructions like those
can be used.

Regards,
Cesare
___
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] File system path PEP, 3rd draft

[Larry Hastings]

On 05/17/2016 02:57 AM, Brett Cannon wrote:
On Mon, May 16, 2016, 19:02 Ethan Furman > wrote:


Isn't 3.4 now in security-fix mode?


Yes, but because of pathlib's provisional status, Guido backported the 
path attribute from 3.4 forward.


I think this is one reason why Raymond Hettinger says "Python is Guido's 
language, he just lets us use it."



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