On May 28, 2010, at 1:39 PM, Scott Dial wrote:
On 5/27/2010 4:13 AM, Brian Quinlan wrote:
On 27 May 2010, at 17:53, Floris Bruynooghe wrote:
On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote:
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the
ACTIVITY SUMMARY (2010-05-21 - 2010-05-28)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2705 open (+40) / 17957 closed (+21) / 20662 total (+61)
Open issues with patches: 1095
Brian Quinlan brian at sweetapp.com writes:
future is a computing science term of art, like thread. Anyway,
this has been discussed in the past and Guido was happy with the name.
I've not seen this mentioned, but on such a long thread I might have missed it:
we already have a __future__
I had the strong impression that there was a policy that x.y.z bugfix
releases should only fix bugs and not add new features and revise
current ones. The rationale, as I understood it, is that x.y.z releases
should be increasingly better implementations of a stable x.y feature
set. Adding
On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote:
I've not seen this mentioned, but on such a long thread I might have
missed it: we already have a __future__ module, as in
from __future__ import with_statement
and to my mind, this is a potential point of confusion with the term
future.
Vinay Sajip wrote:
Brian Quinlan brian at sweetapp.com writes:
future is a computing science term of art, like thread. Anyway,
this has been discussed in the past and Guido was happy with the name.
I've not seen this mentioned, but on such a long thread I might have missed
it:
we
On May 28, 2010, at 8:12 PM, Steven D'Aprano st...@pearwood.info
wrote:
On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote:
I've not seen this mentioned, but on such a long thread I might have
missed it: we already have a __future__ module, as in
from __future__ import with_statement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Terry Reedy wrote:
I had the strong impression that there was a policy that x.y.z bugfix
releases should only fix bugs and not add new features and revise
current ones. The rationale, as I understood it, is that x.y.z releases
should be
Terry Reedy wrote:
I had the strong impression that there was a policy that x.y.z bugfix
releases should only fix bugs and not add new features and revise
current ones. The rationale, as I understood it, is that x.y.z releases
should be increasingly better implementations of a stable x.y
2010/5/28 Steve Holden st...@holdenweb.com:
Terry Reedy wrote:
http://bugs.python.org/issue8840
I was rather shocked to be told that the code-breaking and
policy-violating change was intentional because being 'more consistent
with other file-handling APIs out there' was somehow more important
On 29/05/10 10:19, Jesse Noller wrote:
In my opinion, it is high time for the std lib to pay more attention to
the final Zen:
Namespaces are one honking great idea -- let's do more of those!
Yes, your suggestion for how to move things is the way we would want to
do it, and in the back of my
On 29/05/10 09:03, Terry Reedy wrote:
After filing
http://bugs.python.org/issue8840
I was rather shocked to be told that the code-breaking and
policy-violating change was intentional because being 'more consistent
with other file-handling APIs out there' was somehow more important than
On 29/05/10 09:03, Terry Reedy wrote:
After filing
http://bugs.python.org/issue8840
I was rather shocked to be told that the code-breaking and
policy-violating change was intentional because being 'more consistent
with other file-handling APIs out there' was somehow more important than
Steven D'Aprano wrote:
I have suggested a way to move the existing concurrency stuff without
breaking backwards compatibility, and Terry Reedy asked if it would
work. I haven't seen any responses, either positive or negative.
For the record, my suggestion was:
for each concurrency modules:
14 matches
Mail list logo
