Re: [Python-Dev] doctest, unicode repr, and 2to3

Glyph Lefkowitz wrote: > > On Mar 4, 2010, at 11:30 PM, Barry Warsaw wrote: > >> If you really want to test that it's a unicode, shouldn't you actually >> test >> its type? (I'm not sure what would happen with that under 2to3.) > > Presumably 2to3 will be smart enough to translate 'unicode' to

Re: [Python-Dev] doctest, unicode repr, and 2to3

"Martin v. Löwis" wrote: [...] > Any proposal appreciated. I propose screaming “help me, I have written a test suite using nothing but string matching assertions, what is wrong with me?!” -Andrew. ___ Python-Dev mailing list Python-Dev@python.org http:

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

A young library solving an old problem in a way that conflicts with many of the other implementations available for years and with zero apparent users in the wild is not an appropriate candidate for a PEP. On Fri, Mar 5, 2010 at 1:03 AM, Brian Quinlan wrote: > Hi all, > > I recently submitted a d

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman wrote: > A young library solving an old problem in a way that conflicts with > many of the other implementations available for years and with zero > apparent users in the wild is not an appropriate candidate for a PEP. > Baloney. A young library pro

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

I revert my objections. I still would like to see this in use "in the wild" and I might even use it thusly, myself. On Fri, Mar 5, 2010 at 9:50 AM, Jesse Noller wrote: > On Fri, Mar 5, 2010 at 7:45 AM, Calvin Spealman wrote: >> A young library solving an old problem in a way that conflicts with

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

Jesse Noller wrote: > The reason *why* is that I would like to also move the abstractions I > have in multiprocessing *out* of that module, make them work with both > threads and processes (if it makes sense) and reduce the > multiprocessing module to the base primitive Process object. A > concurre

Re: [Python-Dev] doctest, unicode repr, and 2to3

Le Thu, 4 Mar 2010 23:30:12 -0500, Barry Warsaw a écrit : > > If you really want to test that it's a unicode, shouldn't you > actually test its type? (I'm not sure what would happen with that > under 2to3.) Besides, the type of the string is very rarely > important, so I think the u-prefix and

Re: [Python-Dev] doctest, unicode repr, and 2to3

On 05/03/2010 15:56, Antoine Pitrou wrote: Le Thu, 4 Mar 2010 23:30:12 -0500, Barry Warsaw a écrit : If you really want to test that it's a unicode, shouldn't you actually test its type? (I'm not sure what would happen with that under 2to3.) Besides, the type of the string is very rarely

Re: [Python-Dev] doctest, unicode repr, and 2to3

On Mar 05, 2010, at 10:56 AM, Antoine Pitrou wrote: >String type is actually very important, if you don't want your >application/library to fail in the face of non-ASCII data. > >That's why we did all this thing in py3k, after all :) That's not actually what I mean. I meant that in doctests, you

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 11:21 AM, 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 > ...". Futures is a common term for this, and implemented named this in other la

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

>>> import futures >> >> +1 on the idea, -1 on the name.  It's too similar to "from __future__ import >> ...". Jesse> Futures is a common term for this, and implemented named this in Jesse> other languages. I don't think we should be adopting things that Jesse> are co

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 11:56 AM, wrote: >    >>> import futures >    >> >    >> +1 on the idea, -1 on the name.  It's too similar to "from __future__ > import >    >> ...". > >    Jesse> Futures is a common term for this, and implemented named this in >    Jesse> other languages. I don't think w

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: > > On Fri, Mar 5, 2010 at 11:21 AM, 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 > > ...". > >

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller wrote: > http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html > According to that link, Java has a module named "Concurrent" with an interface named "Future". You're proposing a module named "Futures" with a class named "Future".

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

Jesse> http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html Without reading that I can assure you that not everybody has drunk the Java Kool-Aid. Just because Sun thought it was a fine term doesn't mean everyone else will. I've been a professional programmer for about 30

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach wrote: > On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller wrote: >> >> http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html > >  According to that link, Java has a module named "Concurrent" with an > interface named "Future".  You'r

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 05:06 pm, c...@hagenlocher.org wrote: On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: On Fri, Mar 5, 2010 at 11:21 AM, 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

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 9:55 AM, Jesse Noller wrote: > On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach > wrote: >> On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller wrote: >>> >>> http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html >> >>  According to that link, Java has a module

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

s...@pobox.com wrote: > > Jesse> > http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html > > Without reading that I can assure you that not everybody has drunk the Java > Kool-Aid. Just because Sun thought it was a fine term doesn't mean everyone > else will. I've been a

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

http://home.pipeline.com/~hbaker1/Futures.html (1977) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] argparse ugliness

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. ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 10:30 AM, wrote: > On 05:06 pm, c...@hagenlocher.org wrote: >> >> On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: >>> >>> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >>> wrote: >>> > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan >>> > wrote: >>> >> >>> >> impo

Re: [Python-Dev] argparse ugliness

On Fri, Mar 5, 2010 at 12:51, 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. > What else would you propose? FWIW, this is

Re: [Python-Dev] doctest, unicode repr, and 2to3

On 3/4/2010 11:11 PM, "Martin v. Löwis" wrote: Johan Harjano ran into an interesting problem when trying to run the Django test suite under Python 3.1. Django has doctests of the form a6.headline u'Default headline' Even when converting the doctest with 2to3, the expected output is unmodifie

Re: [Python-Dev] doctest, unicode repr, and 2to3

Andrew Bennetts wrote: > "Martin v. Löwis" wrote: > [...] >> Any proposal appreciated. > > I propose screaming “help me, I have written a test suite using nothing > but string matching assertions, what is wrong with me?!” Thanks a lot. Regards, Martin

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On 07:10 pm, gu...@python.org wrote: On Fri, Mar 5, 2010 at 10:30 AM, wrote: On 05:06 pm, c...@hagenlocher.org wrote: On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller wrote: On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach wrote: > On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan > wrote:

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 09:55, Jesse Noller wrote: > On Fri, Mar 5, 2010 at 12:28 PM, Daniel Stutzbach > wrote: > > On Fri, Mar 5, 2010 at 11:03 AM, Jesse Noller wrote: > >> > >> http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html > > > > According to that link, Java has a mo

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Noller wrote: > On Fri, Mar 5, 2010 at 11:21 AM, 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 >> ...". > >

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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, return_when=ALL_COMPLETED)``? On Thu, Mar 4, 2010 at 22:

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 3:31 PM, Brett Cannon wrote: > > So I don't quite get what you are after here. Are you wanting to eventually > have a generic pool class that you can simply import and use that is always > set to the best option for the platform? > And as for moving stuff from multiprocessi

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 12:18 PM, wrote: > The "explicit" futures on the wikipedia page seems to cover what is commonly > referred to as a future.  For example, Java's futures look like this. > > The "implicit" futures are what is generally called a promise.  For example, > E's promises look like

Re: [Python-Dev] doctest, unicode repr, and 2to3

On Thu, Mar 4, 2010 at 8:11 PM, "Martin v. Löwis" wrote: > Johan Harjano ran into an interesting problem when trying to run the > Django test suite under Python 3.1. > > Django has doctests of the form > a6.headline > u'Default headline' > > Even when converting the doctest with 2to3, the exp

Re: [Python-Dev] doctest, unicode repr, and 2to3

> The issue shows (yet again) a general problem with doctests being > overspecified -- the test shouldn't care that the output starts with > 'u', it should only care that the value is unicode, but there's no > easy way to express this in doctests. But since these doctests exist I > suggest that the

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jesse Noller wrote: >> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >> wrote: >>> On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan wrote: import futures >>> +1 on the idea, -1 on the

Re: [Python-Dev] doctest, unicode repr, and 2to3

Am 05.03.2010 20:37, schrieb Terry Reedy: > On 3/4/2010 11:11 PM, "Martin v. Löwis" wrote: >> Johan Harjano ran into an interesting problem when trying to run the >> Django test suite under Python 3.1. >> >> Django has doctests of the form >> > a6.headline >> u'Default headline' >> >> Even when

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 1:42 PM, Jesse Noller wrote: > On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jesse Noller wrote: >>> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >>> wrote: On Fri, Mar 5, 2010 at 12:03 AM, Brian Quin

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

Am 04.03.2010 21:20, schrieb Brett Cannon: > 1) I miss not having the affected files listed in the subject line. I actually like the (first line of the) commit message better. It communicates much better what the change is about (and for me, if I want to look at/review it). However, what I miss

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 cancelled and the method will return False

Re: [Python-Dev] doctest, unicode repr, and 2to3

Martin v. Löwis wrote: Johan Harjano ran into an interesting problem when trying to run the Django test suite under Python 3.1. Django has doctests of the form >>> a6.headline u'Default headline' Even when converting the doctest with 2to3, the expected output is unmodified. However, in 3.x, th

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Noller wrote: > On Fri, Mar 5, 2010 at 3:33 PM, Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jesse Noller wrote: >>> On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach >>> wrote: On Fri, Mar 5, 2010 at 12:03

Re: [Python-Dev] argparse ugliness

On Fri, Mar 5, 2010 at 10:51 AM, 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. If it really bothers you, you can use:

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 2:54 PM, 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 exec

Re: [Python-Dev] argparse ugliness

Le Fri, 05 Mar 2010 13:51:15 -0500, Neal Becker a écrit : > I generally enjoy argparse, but one thing I find rather > ugly and unpythonic. > > parser.add_argument ('--plot', action='store_true') I would argue that a string is actually more Pythonic than integers or anonymous objects repurpos

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

Guido van Rossum writes: > "Future" is a pretty standard CS term for this concept (as noted > "promise" is another), I like the term "promise" better. "Future" is very generic ("not now, but later"), whereas a "promise" is something I don't get from you now, but you will give me later. The wi

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

exar...@twistedmatrix.com writes: > The "explicit" futures on the wikipedia page seems to cover what is > commonly referred to as a future. For example, Java's futures look like > this. > > The "implicit" futures are what is generally called a promise. For > example, E's promises look

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

At 01:03 AM 3/5/2010, Brian Quinlan wrote: Hi all, I recently submitted a daft PEP for a package designed to make it easier to execute Python functions asynchronously using threads and processes. It lets the user focus on their computational problem without having to build explicit thread/proces

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 system in the stdlib ... Futures are a blocking construct; they don't involve an event loop. _

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

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 system in the stdlib ... Futures are a blocking cons

Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously

On Fri, Mar 5, 2010 at 9:47 PM, Stephen J. Turnbull wrote: > Guido van Rossum writes: > >  > "Future" is a pretty standard CS term for this concept (as noted >  > "promise" is another), > > I like the term "promise" better.  "Future" is very generic ("not now, > but later"), whereas a "promise" is