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
>
ACTIVITY SUMMARY (2015-02-27 - 2015-03-06)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4804 (+16)
closed 30555 (+45)
total 35359 (+61)
Open issues wit
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 from the SIG again, and so now I present t
On 06.03.15 14:53, Victor Stinner wrote:
I propose to ignore BrokenPipeError in Popen.__exit__, as done in
communicate(), for convinience:
http://bugs.python.org/issue23570
Serhiy wants to keep BrokenPipeError, he wrote that file.close()
should not ignore write errors (read the issue for details
Hi,
=> I propose to ignore BrokenPipeError on Popen.__exit__(), what do you think?
A recent issue fixed subprocess.Popen.__exit__() to read the exit
status of the child process, even if stdin.close() raised a
BrokenPipeError:
http://bugs.python.org/issue21619
When I saw the issue, I was surprise
23 matches
Mail list logo
