On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote:
On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan
wrote:
import futures
+1 on the idea, -1 on the name. It's too similar to "from
__future__ import ...".
Also, the PEP should probably link to the discussions on stdlib-sig?
I thought about
On 6 Mar 2010, at 07:38, Brett Cannon wrote:
The PEP says that futures.wait() should only use keyword arguments
past its first positional argument, but the PEP has the function
signature as ``wait(fs, timeout=None, return_when=ALL_COMPLETED)``.
Should it be ``wait(fs, *, timeout=None, retu
On 6 Mar 2010, at 08:42, Jesse Noller wrote:
If people agree with this; do you feel the proposal of said namespace
should be a separate PEP, or piggy back on this? I don't want to piggy
back on Brian's hard work.
It doesn't really matter to me.
We can either update this PEP to propose the con
On 6 Mar 2010, at 09:54, Antoine Pitrou wrote:
Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan a écrit :
The PEP lives here:
http://python.org/dev/peps/pep-3148/
Ok, here is my take on it:
cancel()
Attempt to cancel the call. If the call is currently being executed
then it cannot be ca
On 6 Mar 2010, at 17:50, Phillip J. Eby wrote:
At 01:19 AM 3/6/2010, Jeffrey Yasskin wrote:
On Fri, Mar 5, 2010 at 10:11 PM, Phillip J. Eby > wrote:
> I'm somewhat concerned that, as described, the proposed API ...
[creates] yet another alternative (and
> mutually incompatible) event loop sy
Brian Quinlan wrote:
>
> On 6 Mar 2010, at 08:42, Jesse Noller wrote:
>> If people agree with this; do you feel the proposal of said namespace
>> should be a separate PEP, or piggy back on this? I don't want to piggy
>> back on Brian's hard work.
>
> It doesn't really matter to me.
>
> We can ei
Jeffrey Yasskin writes:
> It seems like a good idea to follow the choice other languages have
> used for the name (if they tend to agree)
For the record, I've conceded that point.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
Brian Quinlan wrote:
>> IOW, as far as I can tell from the PEP, it doesn't look like you can
>> compose futures without *global* knowledge of the application... and
>> in and of itself, this seems to negate the PEP's own motivation to
>> prevent duplication of parallel execution handling!
>>
>> Th
Neal Becker wrote:
> I generally enjoy argparse, but one thing I find rather
> ugly and unpythonic.
>
> parser.add_argument ('--plot', action='store_true')
>
> Specifying the argument 'action' as a string is IMO ugly.
It isn't ideal, but having to grab constants from the module isn't ideal
e
On Sat, Mar 6, 2010 at 6:43 AM, Nick Coghlan wrote:
> You may want to consider providing global thread and process executors
> in the futures module itself. Code which just wants to say "do this in
> the background" without having to manage the lifecycle of its own
> executor instance is then fre
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's "Deferred" API has nothing to do with I/O.
___
Python-Dev mailing list
Python-Dev@pyth
Python-devs,
I'm writing to you for some help in understanding the Python grammar. As an
excuse to deep dive into Python's tokenizer / grammar, I decided (as a
hideous, hideous joke) to want to allow braces where colons are allowed (as
flow control).
Starting from PEP 306 (and branch r311), I ha
> 1.) I assume the Grammar/grammar is read top to bottom. Confirm?
Confirm - but this is not surprising: *any* source file is typically
read from top to bottom. Randoma access reading is typically done for
binary files, only.
So you must be asking something else, but I can't guess what that mig
I don't believe argparse's action specification scheme is bad either, but
On 6 Mar 2010, at 13:50 , Nick Coghlan wrote:
>
> you wouldn't get the static name checking that is
> the primary benefit of using named constants in less dynamic languages.
There are quite a few tools which do handle stat
Sorry, re: question one, forgive the ill-formed question. I meant more, are
the parser rules applied "first matching". Essentially trying to confirm
that the parser is "top down" or "bottom up" or whether or not it even
matters.
Thanks for the tip -- it seems to be exactly what I want. To make
I see two possible fixes for this. One is to not silence DeprecationWarning
if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new
subclass of DeprecationWarning called IntegerDivisionWarning and have that
added to the warnings filter so that if it is triggered it is handled
sepa
2010/3/6 Brett Cannon :
> I see two possible fixes for this. One is to not silence DeprecationWarning
> if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new
> subclass of DeprecationWarning called IntegerDivisionWarning and have that
> added to the warnings filter so that if it
I have been playing with the feedback branch of this package for py3
and there seems to be a rather serious bug in the Process version.
Using the code @ http://dpaste.com/hold/168795/
When I was running in debug mode I found that as soon as
p = multiprocessing.Process(
I am also getting an odd error on odd error on exit
Error in atexit._run_exitfuncs:
TypeError: print_exception(): Exception expected for value, str found
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Sat, Mar 6, 2010 at 10:26 AM, Gregg Lind wrote:
> Sorry, re: question one, forgive the ill-formed question. I meant more, are
> the parser rules applied "first matching". Essentially trying to confirm
> that the parser is "top down" or "bottom up" or whether or not it even
> matters.
That's
On Mar 6, 2010, at 4:20 PM, Dj Gilcrease wrote:
I have been playing with the feedback branch of this package for py3
and there seems to be a rather serious bug in the Process version.
Using the code @ http://dpaste.com/hold/168795/
When I was running in debug mode I found that as soon as
On behalf of the Python development team, I'm pleased to announce a release
candidate for the second bugfix release of the Python 3.1 series, Python 3.1.2.
This bug fix release fixes numerous issues found in 3.1.1. This release
candidate has been released to solicit testing and feedback over an p
On behalf of the Python development team, I'm overjoyed to announce the fourth
alpha release of Python 2.7.
Python 2.7 is scheduled (by Guido and Python-dev) to be the last major version
in the 2.x series. Though more major releases have not been absolutely ruled
out, it's likely that the 2.7 rel
"Stephen J. Turnbull" writes:
> I have to admit Jean-Paul's explanation a pretty convincing reason for
> adopting "future" rather than "promise". But I'm with Skip, I would
> prefer that the module be named "future" rather than "futures".
Has anyone in this very long thread raised the issue that
On Mar 6, 2010, at 5:47 PM, Ben Finney
wrote:
"Stephen J. Turnbull" writes:
I have to admit Jean-Paul's explanation a pretty convincing reason
for
adopting "future" rather than "promise". But I'm with Skip, I would
prefer that the module be named "future" rather than "futures".
Has
Jeffrey Yasskin wrote:
The caller can't avoid the error here by querying the future, because
of the problem you point out below, so I'm inclined to think that "the
future was already started" should be a return value rather than an
exception (although that may be my C++ background showing throug
Antoine Pitrou wrote:
I would argue that a string is actually more Pythonic than
integers or anonymous objects repurposed as magic constants.
(I'm looking at things such as SEEK_SET and friends)
Strings are certainly preferable to ints, one reason being that
they display as something meaningfu
Phillip J. Eby wrote:
while at the same time creating yet another alternative (and
mutually incompatible) event loop system in the stdlib, beyond the ones
that are already in asyncore, tkinter, and the various SocketServer
subclasses.
Aaargh... that's the *last* thing we need!
I've been thin
On 06/03/2010 23:37, Greg Ewing wrote:
Phillip J. Eby wrote:
while at the same time creating yet another alternative (and mutually
incompatible) event loop system in the stdlib, beyond the ones that
are already in asyncore, tkinter, and the various SocketServer
subclasses.
Aaargh... that's t
Brian Quinlan wrote:
That recommendation was designed to make it easy to change the API
without breaking code.
I'd don't think that recommendation makes sense anymore any I'll update
the PEP.
I don't think there's anything wrong with stating that the
order of the arguments is not a guarante
On Sat, Mar 6, 2010 at 5:38 PM, Michael Foord wrote:
> On 06/03/2010 23:37, Greg Ewing wrote:
>
>> I've been thinking for a while that it would be a big help
>> if there were one, standardised module in the stdlib for
>> handling async events, and all the other gui toolkits
>> etc. were made to us
Gregg Lind wrote:
Sorry, re: question one, forgive the ill-formed question. I meant more,
are the parser rules applied "first matching". Essentially trying to
confirm that the parser is "top down" or "bottom up" or whether or not
it even matters.
I think pgen would complain if you had two
Michael Foord wrote:
Wouldn't it have to be the Tcl event loop then?
No, tcl/tk would have to be threatened with the comfy chair
until it allowed itself to be spliced into the official
event loop somehow.
--
Greg
___
Python-Dev mailing list
Python-D
Ben> Has anyone in this very long thread raised the issue that Python
Ben> *already* uses this term for the name of a module with a totally
Ben> unrelated purpose; the â__future__â pseudo-module?
Yes, it's already come up. While not quite the same it does remind me of
the __built
On Sat, Mar 6, 2010 at 2:58 PM, Jesse Noller wrote:
> Did you run the provided example code on windows by chance? If so, look at
> the multiprocessing docs, there are restrictions on windows (see the
> __main__ note) - not following the guidelines can result in lots of
> processes spawning.
Yes,
On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's "Deferred" API has nothing to do with I/O.
I see, you just mean the API and not th
On 02:10 am, br...@sweetapp.com wrote:
On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's "Deferred" API has nothing to do with I/O.
On Sat, Mar 6, 2010 at 9:34 PM, wrote:
> On 02:10 am, br...@sweetapp.com wrote:
>>
>> On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
>>>
>>> At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futur
After playing with the API for a while & running into many issues with
the examples & tests crashing windows I decided to modify the API a
little and fix up the examples so they dont crash windows based
computers.
http://code.google.com/p/pythonfutures/issues/detail?id=1
API Change that changes t
At 01:10 PM 3/7/2010 +1100, Brian Quinlan wrote:
On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
At 05:32 AM 3/6/2010, Brian Quinlan wrote:
Using twisted (or any other asynchronous I/O framework) forces you to
rewrite your I/O code. Futures do not.
Twisted's "Deferred" API has nothing to do w
Greg Ewing wrote:
> The thing to consider, I think, is whether it makes sense in
> a large proportion of use cases to ignore the fact that the
> cancel failed and carry on regardless. If not, then raising an
> exception makes it much harder to accidentally ignore the
> situation.
Cancelling operat
P.J. Eby wrote:
> (Personally, I think it would be better to just drop the ambitious title
> and scope, and go for the "nice task queue" scope. I imagine, too, that
> in that case Jean-Paul wouldn't need to worry about it being raised as a
> future objection to Deferreds or some such getting into
42 matches
Mail list logo
