On Thu, 27 May 2010 21:57:48 -0400
Reid Kleckner wrote:
>
> Unrelatedly, I feel like this behavior of waiting for the thread to
> terminate usually manifests as deadlocks when the main thread throws
> an uncaught exception. The application then no longer responds
> properly to interrupts, since
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
Ave
Brian Quinlan 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__" modu
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 featu
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
> "
Vinay Sajip wrote:
> Brian Quinlan 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:
> w
On May 28, 2010, at 8:12 PM, Steven D'Aprano
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
and to my mind, this
-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 incr
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 fe
2010/5/28 Steve Holden :
> 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 than
>> co
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
consistenc
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
consistenc
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
