Does anybody know if http://vote.python.org is already operational?
I decided to start a separate thread for TransformDict name, because I
want to change it.
Current implementation of PEP 455 only touches dictionary keys and it
is more narrow than the name suggests. I'd reserve TransformDict name
Le Sun, 15 Sep 2013 06:46:08 -0700,
Ethan Furman et...@stoneleaf.us a écrit :
I see PEP 428 is both targeted at 3.4 and still in draft status.
What remains to be done to ask for pronouncement?
I think I have a couple of items left to integrate in the PEP.
Mostly it needs me to take a bit of
I hope there is a volunteer for delegate.
--Guido van Rossum (sent from Android phone)
On Sep 16, 2013 1:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Sun, 15 Sep 2013 06:46:08 -0700,
Ethan Furman et...@stoneleaf.us a écrit :
I see PEP 428 is both targeted at 3.4 and still in draft
On 16 September 2013 16:42, Guido van Rossum gu...@python.org wrote:
I'm ready to accept this PEP. Because I haven't read this entire thread (and
60 messages about random diversions is really too much to try and catch up
on) I'll give people 24 hours to remind me of outstanding rejections.
I
2013/9/16 Antoine Pitrou solip...@pitrou.net:
Le Sun, 15 Sep 2013 06:46:08 -0700,
Ethan Furman et...@stoneleaf.us a écrit :
I see PEP 428 is both targeted at 3.4 and still in draft status.
What remains to be done to ask for pronouncement?
I think I have a couple of items left to integrate
I'm ready to accept this PEP. Because I haven't read this entire thread
(and 60 messages about random diversions is really too much to try and
catch up on) I'll give people 24 hours to remind me of outstanding
rejections.
I also haven't reviewed the code in any detail, but I believe the code
On 9/15/2013 11:28 PM, anatoly techtonik wrote:
Does anybody know if http://vote.python.org is already operational?
I decided to start a separate thread for TransformDict name, because I
want to change it.
Current implementation of PEP 455 only touches dictionary keys and it
is more narrow than
On Mon, 16 Sep 2013 19:06:37 +0200
Charles-François Natali cf.nat...@gmail.com wrote:
2013/9/16 Antoine Pitrou solip...@pitrou.net:
Le Sun, 15 Sep 2013 06:46:08 -0700,
Ethan Furman et...@stoneleaf.us a écrit :
I see PEP 428 is both targeted at 3.4 and still in draft status.
What remains
Russell E. Owen ro...@uw.edu wrote:
In article b3293155-e4d5-4389-a555-c31bc49ce...@gmail.com,
Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Sep 14, 2013, at 1:32 PM, Ned Deily n...@acm.org wrote:
The
most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x,
On Mon, 16 Sep 2013 15:48:54 -0400
Brett Cannon br...@python.org wrote:
So I would like to propose the following API change:
- Path.stat() (and stat-accessing methods such as get_mtime()...)
returns an uncached stat object by default
- Path.cache_stat() can be called to return the
In article b3293155-e4d5-4389-a555-c31bc49ce...@gmail.com,
Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Sep 14, 2013, at 1:32 PM, Ned Deily n...@acm.org wrote:
The
most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have
a mature clang but do not provide a
On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 16 Sep 2013 19:06:37 +0200
Charles-François Natali cf.nat...@gmail.com wrote:
2013/9/16 Antoine Pitrou solip...@pitrou.net:
Le Sun, 15 Sep 2013 06:46:08 -0700,
Ethan Furman et...@stoneleaf.us a écrit :
2013/9/16 Brett Cannon br...@python.org:
Any reason why stat() can't get a keyword-only cached=True argument instead?
Or have stat() never cache() but stat_cache() always so that people can
choose if they want fresh or cached based on API and not whether some
library happened to make a
On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon br...@python.org wrote:
On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
So I would like to propose the following API change:
- Path.stat() (and stat-accessing methods such as get_mtime()...)
returns an uncached
Meh...I hate it when tools download stuff without me noticing.
Honestly, a separate 10.6 build would work well. Plus, if a new Clang
versions includes some awesome feature that could make Python builds
better, you'd be able to take advantage of it better.
On Mon, Sep 16, 2013 at 2:56 PM, Bill
On 9/16/2013 4:14 PM, R. David Murray wrote:
Well, we tend to avoid single boolean arguments in favor of differently
named functions.
The stdlib has lots of boolean arguments. My impression is that they are
to be avoided when they would change the return type or otherwise do
something
On Mon, 16 Sep 2013 16:14:43 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon br...@python.org wrote:
On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
So I would like to propose the following API change:
-
On 17 Sep 2013 06:45, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 16 Sep 2013 16:14:43 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon br...@python.org
wrote:
On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou solip...@pitrou.net
Hi,
Thanks to the early remarks on the PEP 454, I redesigned and enhanced
the API of the new tracemalloc module. Changes:
* it is now possibility to record more than 1 frame per memory allocation
* add filters on filename and line number
* new GroupedStats and StatsDiff class to generate and
On Mon, Sep 16, 2013 at 08:42:12AM -0700, Guido van Rossum wrote:
I'm ready to accept this PEP. Because I haven't read this entire thread
(and 60 messages about random diversions is really too much to try and
catch up on) I'll give people 24 hours to remind me of outstanding
rejections.
I
On Mon, Sep 16, 2013 at 4:59 PM, Steven D'Aprano st...@pearwood.infowrote:
On Mon, Sep 16, 2013 at 08:42:12AM -0700, Guido van Rossum wrote:
I'm ready to accept this PEP. Because I haven't read this entire thread
(and 60 messages about random diversions is really too much to try and
catch
Terry Reedy writes:
On 9/16/2013 4:14 PM, R. David Murray wrote:
Well, we tend to avoid single boolean arguments in favor of differently
named functions.
The stdlib has lots of boolean arguments. My impression is that they are
to be avoided when they would change the return type
22 matches
Mail list logo
