Here is the latest draft of the PEP. I have closed the issue of file name
formatting thanks to the informal poll results being very clear on the
preferred format and also closed the idea of embedding the optimization
level in the bytecode file metadata (that can be another PEP if someone
cares to w
Hi Brett,
On 6 March 2015 at 19:11, Brett Cannon wrote:
> I disagree with your premise that .pyo files don't have a noticeable effect
> on performance. If you don't use asserts a lot then there is no effect, but
> if you use them heavily or have them perform expensive calculations then
> there is
On Wed, Mar 11, 2015 at 05:34:10PM +, Brett Cannon wrote:
> I have a poll going on G+ to see what people think of the various proposed
> file name formats at
> https://plus.google.com/u/0/+BrettCannon/posts/fZynLNwHWGm . Feel free to
> vote if you have an opinion.
G+ hates my browser and won'
On Wed, Mar 11, 2015 at 5:29 PM Armin Rigo wrote:
> Hi Brett,
>
> On 6 March 2015 at 19:11, Brett Cannon wrote:
> > I disagree with your premise that .pyo files don't have a noticeable
> effect
> > on performance. If you don't use asserts a lot then there is no effect,
> but
> > if you use them
On Fri, Mar 6, 2015 at 6:49 PM Benjamin Peterson
wrote:
>
>
> On Fri, Mar 6, 2015, at 15:11, Brett Cannon wrote:
> >
> > OK, but that doesn't influence the PEP's goal of dropping .pyo files.
>
> Correct.
>
> >
> > Are you suggesting that the tag be changed to be less specific to
> > optimizations
For the record here: +1 on the PEP from me (the comments I made on
import-sig have already incorporated into this version of the PEP)
On 8 March 2015 at 08:03, Brett Cannon wrote:
>
>
> On Sat, Mar 7, 2015 at 12:39 PM Scott Dial
> wrote:
>>
>> On 2015-03-06 11:34 AM, Brett Cannon wrote:
>> > Thi
On Mar 07, 2015, at 12:30 PM, Scott Dial wrote:
>As a packager, this PEP is a bit silent on it's expectations about what
>will happen with (for instance) Debian and Fedora packages for Python.
>My familiarity is with Fedora, and on that platform, we ship .pyc and
>.pyo files (using -O for the .pyo
On Sat, Mar 7, 2015 at 12:39 PM Scott Dial
wrote:
> On 2015-03-06 11:34 AM, Brett Cannon wrote:
> > This PEP proposes eliminating the concept of PYO files from Python.
> > To continue the support of the separation of bytecode files based on
> > their optimization level, this PEP proposes extendin
On 2015-03-06 11:34 AM, Brett Cannon wrote:
> This PEP proposes eliminating the concept of PYO files from Python.
> To continue the support of the separation of bytecode files based on
> their optimization level, this PEP proposes extending the PYC file
> name to include the optimization level in b
On Sat, Mar 7, 2015 at 9:29 AM Ron Adam wrote:
>
>
> On 03/07/2015 04:58 AM, Steven D'Aprano wrote:
> > On Fri, Mar 06, 2015 at 08:00:20PM -0500, Ron Adam wrote:
> >
> >> >Have you considered doing this by having different magic numbers in the
> >> >.pyc file for standard, -O, and -O0 compiled by
On 03/07/2015 04:58 AM, Steven D'Aprano wrote:
On Fri, Mar 06, 2015 at 08:00:20PM -0500, Ron Adam wrote:
>Have you considered doing this by having different magic numbers in the
>.pyc file for standard, -O, and -O0 compiled bytecode files? Python
>already checks that number and recompiles th
On Fri, Mar 06, 2015 at 08:00:20PM -0500, Ron Adam wrote:
> Have you considered doing this by having different magic numbers in the
> .pyc file for standard, -O, and -O0 compiled bytecode files? Python
> already checks that number and recompiles the files if it's not what it's
> expected to be
On 03/06/2015 11:34 AM, Brett Cannon wrote:
There are currently two open issues, although one is purely a bikeshed
topic on formatting of file names so I don't really consider it open for
change from what is proposed in the PEP without Guido saying he hates my
preference or someone having a re
On Fri, Mar 6, 2015 at 6:49 PM Benjamin Peterson
wrote:
>
>
> On Fri, Mar 6, 2015, at 15:11, Brett Cannon wrote:
> >
> > OK, but that doesn't influence the PEP's goal of dropping .pyo files.
>
> Correct.
>
> >
> > Are you suggesting that the tag be changed to be less specific to
> > optimizations
On Fri, Mar 6, 2015 at 5:47 PM Antoine Pitrou wrote:
> On Sat, 7 Mar 2015 09:34:20 +1100
> Steven D'Aprano wrote:
>
> > On Fri, Mar 06, 2015 at 09:37:05PM +0100, Antoine Pitrou wrote:
> > > On Fri, 06 Mar 2015 18:11:19 +
> > > Brett Cannon wrote:
> > > > And the dropping of docstrings does
On Fri, Mar 6, 2015 at 3:37 PM Antoine Pitrou wrote:
> On Fri, 06 Mar 2015 18:11:19 +
> Brett Cannon wrote:
> > And the dropping of docstrings does have an impact on
> > memory usage when you use Python at scale.
>
> What kind of "scale" are you talking about? Do you have any numbers
> about
On Fri, Mar 6, 2015, at 15:11, Brett Cannon wrote:
>
> OK, but that doesn't influence the PEP's goal of dropping .pyo files.
Correct.
>
> Are you suggesting that the tag be changed to be less specific to
> optimizations and more free-form? Like
> `importlib.cpython-35.__no-asserts_no-docstrin
On Fri, Mar 6, 2015, at 15:13, Chris Angelico wrote:
> On Sat, Mar 7, 2015 at 6:09 AM, Benjamin Peterson
> wrote:
> > I think it would be preferable deprecate -O and -OO and replace them
> > with flags like --no-docstrings or --no-asserts. Ideally, "optimization"
> > levels shouldn't change prog
On Sat, 7 Mar 2015 09:34:20 +1100
Steven D'Aprano wrote:
> On Fri, Mar 06, 2015 at 09:37:05PM +0100, Antoine Pitrou wrote:
> > On Fri, 06 Mar 2015 18:11:19 +
> > Brett Cannon wrote:
> > > And the dropping of docstrings does have an impact on
> > > memory usage when you use Python at scale.
>
On Fri, Mar 06, 2015 at 09:37:05PM +0100, Antoine Pitrou wrote:
> On Fri, 06 Mar 2015 18:11:19 +
> Brett Cannon wrote:
> > And the dropping of docstrings does have an impact on
> > memory usage when you use Python at scale.
>
> What kind of "scale" are you talking about? Do you have any numbe
On Fri, 06 Mar 2015 18:11:19 +
Brett Cannon wrote:
> And the dropping of docstrings does have an impact on
> memory usage when you use Python at scale.
What kind of "scale" are you talking about? Do you have any numbers
about such impact?
> You're also assuming that we will never develop an
On Fri, Mar 6, 2015 at 2:09 PM Benjamin Peterson
wrote:
>
>
> On Fri, Mar 6, 2015, at 13:34, Brett Cannon wrote:
> > On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar
> > wrote:
> >
> > > On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon wrote:
> > >
> > >>
> > >>
> > >> On Fri, Mar 6, 2015 at 1:03 PM Mar
On Sat, Mar 7, 2015 at 6:09 AM, Benjamin Peterson wrote:
> I think it would be preferable deprecate -O and -OO and replace them
> with flags like --no-docstrings or --no-asserts. Ideally, "optimization"
> levels shouldn't change program semantics.
Plenty of C compilers have optimization levels th
On Fri, Mar 6, 2015, at 13:34, Brett Cannon wrote:
> On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar
> wrote:
>
> > On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon wrote:
> >
> >>
> >>
> >> On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon wrote:
> >>
> >>>
> >>> On 06/03/15 16:34, Brett Cannon wrote:
> >
Thanks! All suggestions applied to my local copy.
On Fri, Mar 6, 2015 at 1:55 PM Ethan Furman wrote:
> On 03/06/2015 08:34 AM, Brett Cannon wrote:
> > Over on the import-sig I proposed eliminating the concept of .pyo files
> since they only signify that /some/ optimization
> > took place, not /w
On 03/06/2015 08:34 AM, Brett Cannon wrote:
> Over on the import-sig I proposed eliminating the concept of .pyo files since
> they only signify that /some/ optimization
> took place, not /what/ optimizations took place. Everyone on the SIG was
> positive with the idea so I wrote a PEP, got
> posi
On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar wrote:
> On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon wrote:
>
>>
>>
>> On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon wrote:
>>
>>>
>>> On 06/03/15 16:34, Brett Cannon wrote:
>>> > Over on the import-sig I proposed eliminating the concept of .pyo files
On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon wrote:
>
>
> On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon wrote:
>
>>
>> On 06/03/15 16:34, Brett Cannon wrote:
>> > Over on the import-sig I proposed eliminating the concept of .pyo files
>> > since they only signify that /some/ optimization took plac
On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon wrote:
>
> On 06/03/15 16:34, Brett Cannon wrote:
> > Over on the import-sig I proposed eliminating the concept of .pyo files
> > since they only signify that /some/ optimization took place, not
> > /what/ optimizations took place. Everyone on the SIG w
On 06/03/15 16:34, Brett Cannon wrote:
Over on the import-sig I proposed eliminating the concept of .pyo files
since they only signify that /some/ optimization took place, not
/what/ optimizations took place. Everyone on the SIG was positive with
the idea so I wrote a PEP, got positive feedback
On Fri, Mar 6, 2015 at 9:34 AM, Brett Cannon wrote:
> Not specifying the optimization level when it is at 0
> -
>
> It has been suggested that for the common case of when the
> optimizations are at level 0 that the entire part of the file name
>
31 matches
Mail list logo
