On Sat, 7 Mar 2015 09:34:20 +1100
Steven D'Aprano st...@pearwood.info wrote:
On Fri, Mar 06, 2015 at 09:37:05PM +0100, Antoine Pitrou wrote:
On Fri, 06 Mar 2015 18:11:19 +
Brett Cannon br...@python.org wrote:
And the dropping of docstrings does have an impact on
memory usage when
On Fri, Mar 6, 2015 at 5:47 PM Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 7 Mar 2015 09:34:20 +1100
Steven D'Aprano st...@pearwood.info wrote:
On Fri, Mar 06, 2015 at 09:37:05PM +0100, Antoine Pitrou wrote:
On Fri, 06 Mar 2015 18:11:19 +
Brett Cannon br...@python.org 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 and more free-form? Like
On Fri, Mar 6, 2015 at 3:37 PM Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 06 Mar 2015 18:11:19 +
Brett Cannon br...@python.org 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
On Fri, Mar 6, 2015, at 15:13, Chris Angelico wrote:
On Sat, Mar 7, 2015 at 6:09 AM, Benjamin Peterson benja...@python.org
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
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
On Fri, Mar 6, 2015 at 6:49 PM Benjamin Peterson benja...@python.org
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
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
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
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
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
On Fri, Mar 6, 2015 at 9:34 AM, Brett Cannon bcan...@gmail.com 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
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 1:03 PM Mark Shannon m...@hotpy.org 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
Thanks! All suggestions applied to my local copy.
On Fri, Mar 6, 2015 at 1:55 PM Ethan Furman et...@stoneleaf.us 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
On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar mistersh...@gmail.com wrote:
On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon br...@python.org wrote:
On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon m...@hotpy.org wrote:
On 06/03/15 16:34, Brett Cannon wrote:
Over on the import-sig I proposed
On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon br...@python.org wrote:
On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon m...@hotpy.org 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/
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
positive
On Fri, Mar 6, 2015, at 13:34, Brett Cannon wrote:
On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar mistersh...@gmail.com
wrote:
On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon br...@python.org wrote:
On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon m...@hotpy.org wrote:
On 06/03/15
On Sat, Mar 7, 2015 at 6:09 AM, Benjamin Peterson benja...@python.org 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
On Fri, Mar 6, 2015 at 2:09 PM Benjamin Peterson benja...@python.org
wrote:
On Fri, Mar 6, 2015, at 13:34, Brett Cannon wrote:
On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar mistersh...@gmail.com
wrote:
On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon br...@python.org wrote:
On
On Fri, 06 Mar 2015 18:11:19 +
Brett Cannon br...@python.org 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
22 matches
Mail list logo
