Re: [Python-Dev] argparse ugliness

2010-03-07 Thread Georg Brandl 
Am 06.03.2010 03:28, schrieb Antoine Pitrou:
> 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 repurposed as magic constants.
> (I'm looking at things such as SEEK_SET and friends)

Me too.  In absence of a separate symbol type, Python itself
uses strings for this purpose (hence the intern()ing business).

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.1.2 release candidate

2010-03-07 Thread Stefan Behnel 

Benjamin Peterson, 06.03.2010 23:13:

A list of changes in 3.1.2rc1 can be found here:

  http://svn.python.org/projects/python/tags/r312rc1/Misc/NEWS


Any reason the fix for bug 7173 didn't make it in? The test case that 
Amaury came up with seems to indicate that this a pretty serious issue.


http://bugs.python.org/issue7173

Stefan

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] argparse ugliness

2010-03-07 Thread Neal Becker 
Brian Curtin wrote:

> 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 the same in optparse.

I would have thought use the object itself, instead of a string that spells 
the object's name.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread Jesse Noller 
On Sat, Mar 6, 2010 at 10:09 PM, Dj Gilcrease  wrote:
> 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 the current Executor to ExecutorBase and
> adds a new Executor class that is used like
>
> futures.Executor() # creates an executor that uses threading and a
> max_workers = to the number of cpus
>
> futures.Executor(use='process') # Creates an executor that uses
> multiprocessing and a max_workers = to the number of cpus
>
> futures.Executor(max_workers=5) # threading again, just specifying the
> number of workers
>
> futures.Executor(use='process', max_workers=5) # back to multiprocessing,
> but with the max_workers specified

Making the tests and examples happy on windows is fine; but some
explanation is needed for the API changes.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Silencing DeprecationWarning by default in Python 2.7 is silencing division warnings

2010-03-07 Thread Antoine Pitrou 
Le Sat, 6 Mar 2010 11:43:20 -0800,
Brett Cannon  a écrit :
> 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 separately from what
> DeprecationWarning triggers.

The latter would have my preference. Being able to discriminate between
various classes of deprecations is good. Especially when what you want
is to test for them :)



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.1.2 release candidate

2010-03-07 Thread Antoine Pitrou 
Le Sun, 07 Mar 2010 11:10:52 +0100,
Stefan Behnel  a écrit :
> 
> Any reason the fix for bug 7173 didn't make it in? The test case that 
> Amaury came up with seems to indicate that this a pretty serious
> issue.

The patch needs to properly include an unit test reproducing the test
case.
Also, a committer must step up and apply it. I am currently on vacation
and refrain from doing commits myself.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread P.J. Eby 

At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:

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 the stdlib.)

This may be a terminology thing - to me futures *are* just a nice way to
handle farming tasks out to worker threads or processes. You seem to see
them as something more comprehensive than that.


Actual futures are, yes.  Specifically, futures are a mechanism for 
asynchronous computation, whereas the PEP seems to be all about 
synchronously managing parallel tasks.  That's a huge difference.


Technically, the things in the PEP (and by extension, Java's futures) 
match the letter of the definition of a future, but not (IMO) the 
spirit.  There's no clean way to compose them, and at base they're 
more about parallelism than asynchrony.




I agree the PEP should just target what the current implementation
provides and put whatever scope limitations are needed in the preamble
text to make that clear.


Yep.  I'm just saying "parallel task queueing" is a much better 
description of what the implementation is/does, and would suggest 
renaming Future -> Task and Executor -> WorkerPool or some 
such.  These names would be *much* clearer to people who've never 
heard of futures, as well as more appropriate to the actual scope of 
what this does.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread Jeffrey Yasskin 
On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby  wrote:
> At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:
>>
>> 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 the stdlib.)
>>
>> This may be a terminology thing - to me futures *are* just a nice way to
>> handle farming tasks out to worker threads or processes. You seem to see
>> them as something more comprehensive than that.
>
> Actual futures are, yes.  Specifically, futures are a mechanism for
> asynchronous computation, whereas the PEP seems to be all about
> synchronously managing parallel tasks.  That's a huge difference.
>
> Technically, the things in the PEP (and by extension, Java's futures) match
> the letter of the definition of a future, but not (IMO) the spirit.  There's
> no clean way to compose them, and at base they're more about parallelism
> than asynchrony.

Do you have an example of a language or library that uses the term
"future" to refer to what you're talking about? I'm curious to see
what it looks like.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.1.2 release candidate

2010-03-07 Thread Brad Miller 
I download the source snapshot

./configure --enable-framework
make

...

/usr/bin/install -c -d -m 755 Python.framework/Versions/3.1
if test ""; then \
gcc -o Python.framework/Versions/3.1/Python  -dynamiclib \
-isysroot "" \
-all_load libpython3.1.a -Wl,-single_module \
-install_name
/Library/Frameworks/Python.framework/Versions/3.1/Python \
-compatibility_version 3.1 \
-current_version 3.1 \
-framework CoreFoundation -ldl  -framework
CoreFoundation; \
else \
/usr/bin/libtool -o Python.framework/Versions/3.1/Python
-dynamic  libpython3.1.a \
 -lSystem -lSystemStubs -arch_only x86_64
-install_name /Library/Frameworks/Python.framework/Versions/3.1/Python
-compatibility_version 3.1 -current_version 3.1 -framework CoreFoundation
-ldl  -framework CoreFoundation;\
fi

Undefined symbols:
  "_libintl_bindtextdomain", referenced from:
  _PyIntl_bindtextdomain in libpython3.1.a(_localemodule.o)
  "_libintl_textdomain", referenced from:
  _PyIntl_textdomain in libpython3.1.a(_localemodule.o)
  "_libintl_dgettext", referenced from:
  _PyIntl_dgettext in libpython3.1.a(_localemodule.o)
  "_libintl_gettext", referenced from:
  _PyIntl_gettext in libpython3.1.a(_localemodule.o)
  "_libintl_dcgettext", referenced from:
  _PyIntl_dcgettext in libpython3.1.a(_localemodule.o)
ld: symbol(s) not found
/usr/bin/libtool: internal link edit command failed

I'm on 10.6.2, gcc version 4.2.1

Any hints on where to go from here?


On Sun, Mar 7, 2010 at 8:57 AM, Antoine Pitrou  wrote:

> Le Sun, 07 Mar 2010 11:10:52 +0100,
> Stefan Behnel  a écrit :
> >
> > Any reason the fix for bug 7173 didn't make it in? The test case that
> > Amaury came up with seems to indicate that this a pretty serious
> > issue.
>
> The patch needs to properly include an unit test reproducing the test
> case.
> Also, a committer must step up and apply it. I am currently on vacation
> and refrain from doing commits myself.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/bmiller%40luther.edu
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread P.J. Eby 

At 08:39 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:

On Sun, Mar 7, 2010 at 7:48 AM, P.J. Eby  wrote:
> At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:
>>
>> 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 the stdlib.)
>>
>> This may be a terminology thing - to me futures *are* just a nice way to
>> handle farming tasks out to worker threads or processes. You seem to see
>> them as something more comprehensive than that.
>
> Actual futures are, yes. Â Specifically, futures are a mechanism for
> asynchronous computation, whereas the PEP seems to be all about
> synchronously managing parallel tasks. Â That's a huge difference.
>
> Technically, the things in the PEP (and by extension, Java's futures) match
> the letter of the definition of a future, but not (IMO) the 
spirit. Â There's

> no clean way to compose them, and at base they're more about parallelism
> than asynchrony.

Do you have an example of a language or library that uses the term
"future" to refer to what you're talking about? I'm curious to see
what it looks like.


The wikipedia page menetioned earlier in the discussion has several 
examples.  Twisted's Deferreds are probably the best example of such 
a system in Python, though, as far as I know.  The features proposed 
in the PEP are basically akin to Twisted's deferToThread(), i.e. 
"return a future for running this code in some other thread".


However, you could easily make your own thread or process pool for 
executing tasks, using Deferreds as your "future" objects; 
deferToThread() is not particularly special, it's just one possible 
"executor", to use the PEP's terminology.  Likewise, deferreds are 
not limited to representing parallel task execution - they can also 
represent asynchronous events such as incoming I/O or a waited-for mouse click.


Deferreds allow composing calculation by stacking callbacks (in 
continuation-passing style), but they're most Pythonic (IMO) when 
used with a coroutine wrapping system like Eventlet or my earlier 
peak.events framework, so that you can use them in "yield" 
expressions.  That way you can write synchronous-looking code that 
nonetheless executes asynchronously.


Twisted uses Deferreds extensively, both for I/O and IPC, and of 
course for database access.  However, the 'defer' module itself is 
conceptually distinct from both the I/O system, event loop, and 
threads: it's a largely-generic framework for managing asynchronous 
computation.  Parallel task queueing is simply *one* possible 
application of Deferreds; their actual purpose is to provide a common 
API for working with values that aren't yet known.


That is to say, futures.

In contrast, the PEP manages only a very limited sort of "future" - 
the completion of a single task, which must be synchronously waited 
for.  If one "future" in the PEP needs to wait for another, you tie 
up that thread or process in a busy loop...  which rather limits how 
much parallelism you can have.


Deferreds also allow you to write code that doesn't *care* whether 
the value has been determined or not...  you can simply stack on what 
code you want to have run when the value is available, and it runs 
immediately if the value is there.


Likewise, a deferred is not tied to the execution of a single piece 
of code - it's more of a rendezvous or synchronization point, that 
can be given a value to "fire" with.  (In contrast, the PEP's 
"futures" are tightly coupled to a task execution model: they have a 
notion of running and being cancelled, for example.)


For these reasons, I'd say that Deferreds are much more deserving of 
the title "futures", especially since there is no need to call a 
simple task queue a "futures" system.  (Unless you're Java, I 
suppose, in which case you might want the name for marketing 
reasons.  ;-) But in Python I assume we'd like to call a spade a 
spade, and a task queue a task queue.)


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread R. David Murray 
On Sun, 07 Mar 2010 10:48:09 -0500, "P.J. Eby"  wrote:
> At 02:49 PM 3/7/2010 +1000, Nick Coghlan wrote:
> >I agree the PEP should just target what the current implementation
> >provides and put whatever scope limitations are needed in the preamble
> >text to make that clear.
> 
> Yep.  I'm just saying "parallel task queueing" is a much better 
> description of what the implementation is/does, and would suggest 
> renaming Future -> Task and Executor -> WorkerPool or some 
> such.  These names would be *much* clearer to people who've never 
> heard of futures, as well as more appropriate to the actual scope of 
> what this does.

For what it's worth: I don't have any particular knowledge in this area.
I did loosely follow the stdlib-sig discussion.  I wasn't really sure
exactly what the module was about or what a 'future' was, or why I would
want to use one.  I did get that it was about parallel execution of tasks,
but it seemed like there had to be more to it than that.  Hearing it
called a 'worker pool' makes a lightbulb go off and I can now understand
why this would be a useful facility to have in the standard library.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread Jeffrey Yasskin 
On Sun, Mar 7, 2010 at 9:57 AM, P.J. Eby  wrote:
> At 08:39 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:
>> Do you have an example of a language or library that uses the term
>> "future" to refer to what you're talking about? I'm curious to see
>> what it looks like.
>
> The wikipedia page menetioned earlier in the discussion has several
> examples.  Twisted's Deferreds are probably the best example of such a
> system in Python, though, as far as I know.  The features proposed in the
> PEP are basically akin to Twisted's deferToThread(), i.e. "return a future
> for running this code in some other thread".

Nearly all of the wikipedia page's examples refer to exactly this kind
of system, but with syntax to support it instead of putting it in a
library. The distinction between futures and deferreds is that futures
are designed to block, while deferreds are designed to continue
through callbacks. We could say that futures are to deferreds as
threading.Lock is to mutex.mutex.

> That way you
> can write synchronous-looking code that nonetheless executes asynchronously.

 "Asynchronous" in the PEP refers to how the task behind the future
runs, not how users wait for the future. Is there a better way to say
that?

> Twisted uses Deferreds extensively, both for I/O and IPC, and of course for
> database access.  However, the 'defer' module itself is conceptually
> distinct from both the I/O system, event loop, and threads: it's a
> largely-generic framework for managing asynchronous computation.  Parallel
> task queueing is simply *one* possible application of Deferreds; their
> actual purpose is to provide a common API for working with values that
> aren't yet known.
>
> That is to say, futures.
>
> In contrast, the PEP manages only a very limited sort of "future" - the
> completion of a single task, which must be synchronously waited for.  If one
> "future" in the PEP needs to wait for another, you tie up that thread or
> process in a busy loop...  which rather limits how much parallelism you can
> have.

So is it that you just don't like the idea of blocking, and want to
stop anything that relies on it from getting into the standard
library?

Given the set_result and set_exception methods, it's pretty
straightforward to fill in the value of a future from something that
isn't purely computational. Given a way to register "on-done"
callbacks with the future, it would be straightforward to wait for a
future without blocking, too.

Jeffrey
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] argparse ugliness

2010-03-07 Thread Guido van Rossum 
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker  wrote:
> Brian Curtin wrote:
>
>> 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 the same in optparse.
>
> I would have thought use the object itself, instead of a string that spells
> the object's name.

What object? How would you write the example instead then?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread P.J. Eby 

At 10:59 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:
So is it that you just don't like the idea of blocking, and want to 
stop anything that relies on it from getting into the standard library?


Um, no.  As I said before, call it a "parallel task queue" or 
"parallel task manager" or something to that general effect and I'm on board.


It may not be in the Zen of Python, but ISTM that names should 
generally follow use cases.  It is something of a corollary to "one 
obvious way to do it", in that if you see something whose name 
matches what you want to do, then it should be obvious that that's 
the way in question.  ;-)


The use cases for "parallel task queues", however, are a subset of 
those for "futures" in the general case.  Since the proposed module 
addresses most of the former but very little of the latter, calling 
it futures is inappropriate.


Specifically, it's:

1. Confusing to people who don't know what futures are (see e.g R.D. 
Murray's post), and


2. Underpowered for people who expect/want a more fully-featured 
futures system along the lines of E or Deferreds.


It seems that the only people for whom it's an intuitively correct 
description are people who've only had experience with more limited 
futures models (like Java's).  However, these people should not have 
a problem understanding the notion of parallel task queueing or task 
management, so changing the name isn't really a loss for them, and 
it's a gain for everybody else.



 Given the set_result and set_exception methods, it's pretty 
straightforward to fill in the value of a future from something 
that isn't purely computational.


Those are described as "internal" methods in the PEP; by contrast, 
the Deferred equivalents are part of the public API.



 Given a way to register "on-done" callbacks with the future, it 
would be straightforward to wait for a future without blocking, too.


Yes, and with a few more additions besides that one, you might be on 
the way to an actual competitor for Deferreds.  For example: retry 
support, chaining, logging, API for transparent result processing, 
coroutine support, co-ordination tools like locks, sempaphores and queues, etc.


These are all things you would very likely want or need if you 
actually wanted to write a program using futures as *your main 
computational model*, vs. just needing to toss out some parallel 
tasks in a primarily synchronous program.


Of course, Deferreds are indeed overkill if all you're ever going to 
want is a few parallel tasks, unless you're already skilled in using 
Twisted or some wrapper for it.


So, I totally support having a simple task queue in the stdlib, as 
there are definitely times I would've used such a thing for a quick 
script, if it were available.


However, I've *also* had use cases for using futures as a 
computational model, and so that's what I originally thought this PEP 
was about.  After the use cases were clarified, though, it seems to 
me that *calling* it futures is a bad idea, because it's really just 
a nice task queuing system.


I'm +1 on adding a nice task queuing system, -1 on calling it by any 
other name.  ;-)


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 3.1.2 release candidate

2010-03-07 Thread Brett Cannon 
Do you have MacPorts or Fink installed? If you do then you have a version of
gettext installed that is not compiled properly to work with Python (usually
its a 32-bit/64-bit thing). Best piece of advice is to not use MacPorts/Fink
and use Homebrew instead. =)

On Sun, Mar 7, 2010 at 09:36, Brad Miller  wrote:

>
> I download the source snapshot
>
> ./configure --enable-framework
> make
>
> ...
>
> /usr/bin/install -c -d -m 755 Python.framework/Versions/3.1
> if test ""; then \
> gcc -o Python.framework/Versions/3.1/Python  -dynamiclib \
> -isysroot "" \
> -all_load libpython3.1.a -Wl,-single_module \
> -install_name
> /Library/Frameworks/Python.framework/Versions/3.1/Python \
> -compatibility_version 3.1 \
> -current_version 3.1 \
> -framework CoreFoundation -ldl  -framework
> CoreFoundation; \
> else \
> /usr/bin/libtool -o Python.framework/Versions/3.1/Python
> -dynamic  libpython3.1.a \
>  -lSystem -lSystemStubs -arch_only x86_64
> -install_name /Library/Frameworks/Python.framework/Versions/3.1/Python
> -compatibility_version 3.1 -current_version 3.1 -framework CoreFoundation
> -ldl  -framework CoreFoundation;\
> fi
>
> Undefined symbols:
>   "_libintl_bindtextdomain", referenced from:
>   _PyIntl_bindtextdomain in libpython3.1.a(_localemodule.o)
>   "_libintl_textdomain", referenced from:
>   _PyIntl_textdomain in libpython3.1.a(_localemodule.o)
>   "_libintl_dgettext", referenced from:
>   _PyIntl_dgettext in libpython3.1.a(_localemodule.o)
>   "_libintl_gettext", referenced from:
>   _PyIntl_gettext in libpython3.1.a(_localemodule.o)
>   "_libintl_dcgettext", referenced from:
>   _PyIntl_dcgettext in libpython3.1.a(_localemodule.o)
> ld: symbol(s) not found
> /usr/bin/libtool: internal link edit command failed
>
> I'm on 10.6.2, gcc version 4.2.1
>
> Any hints on where to go from here?
>
>
> On Sun, Mar 7, 2010 at 8:57 AM, Antoine Pitrou wrote:
>
>> Le Sun, 07 Mar 2010 11:10:52 +0100,
>> Stefan Behnel  a écrit :
>> >
>> > Any reason the fix for bug 7173 didn't make it in? The test case that
>> > Amaury came up with seems to indicate that this a pretty serious
>> > issue.
>>
>> The patch needs to properly include an unit test reproducing the test
>> case.
>> Also, a committer must step up and apply it. I am currently on vacation
>> and refrain from doing commits myself.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/bmiller%40luther.edu
>>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 2.6.5 rc 2

2010-03-07 Thread Barry Warsaw 
We are definitely going to need a 2.6.5 rc 2.  We've had a number of critical
issues fixed since rc1 and we have two more critical patches approved for
landing which fix issues on OS X.  I've given Ronald approval in the tracker
to land these two patches.

8066 OS X installer: readline module breaks when targeting on 10.5 or 10.6
8067 OS X Installer: build errors on 10.6 when targeting 10.4 and earlier

These are the only two release blockers left for 2.6.5 (at the moment).  I
would like to cut the rc2 release tomorrow, Monday 2010-03-08, so if anybody
knows of any other bugs you think must go into 2.6.5, mark them release
blockers now so that I can evaluate them.

I really don't want there to be an rc3, and I'd still like to get 2.6.5 final
out on Monday 2010-03-15.  We'll see.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread Dj Gilcrease 
On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller  wrote:
> Making the tests and examples happy on windows is fine; but some
> explanation is needed for the API changes.
>

My primary motivation behind the API change is so there is just a
single public Executor class that you tell what system to use instead
of two separate classes. The use case I was thinking about is when a
user is is unsure which system (threads or processes) they want to use
so they just build the system with the defaults (which is threads)
then it is a little easier to switch it to processes in the future
instead of having to change imports and all instances of the class you
just change the use keyword to switch between systems
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2010-03-07 Thread Guido van Rossum 
On Sun, Mar 7, 2010 at 11:56 AM, P.J. Eby  wrote:
> At 10:59 AM 3/7/2010 -0800, Jeffrey Yasskin wrote:
>>
>> So is it that you just don't like the idea of blocking, and want to stop
>> anything that relies on it from getting into the standard library?
>
> Um, no.  As I said before, call it a "parallel task queue" or "parallel task
> manager" or something to that general effect and I'm on board.
>
> It may not be in the Zen of Python, but ISTM that names should generally
> follow use cases.  It is something of a corollary to "one obvious way to do
> it", in that if you see something whose name matches what you want to do,
> then it should be obvious that that's the way in question.  ;-)
>
> The use cases for "parallel task queues", however, are a subset of those for
> "futures" in the general case.  Since the proposed module addresses most of
> the former but very little of the latter, calling it futures is
> inappropriate.
>
> Specifically, it's:
>
> 1. Confusing to people who don't know what futures are (see e.g R.D.
> Murray's post), and

This is not a problem. We will document what we consider a future.

> 2. Underpowered for people who expect/want a more fully-featured futures
> system along the lines of E or Deferreds.

This sounds like an underhanded slur towards the PEP.

> It seems that the only people for whom it's an intuitively correct
> description are people who've only had experience with more limited futures
> models (like Java's).  However, these people should not have a problem
> understanding the notion of parallel task queueing or task management, so
> changing the name isn't really a loss for them, and it's a gain for
> everybody else.

I expect that the majority of Python users fall either in camp #1
(never heard of futures, will be happy to learn about what Python
calls futures) or camp #3 (have used Java futures). The users of E can
be counted on a few hands. Deferreds are used heavily in some Python
circles but most Python users (myself included) have at most a very
vague idea of them. Also, as you clarify below, Deferreds are so much
more powerful that they can't possibly be mistaken for futures (as
defined by this PEP). Plus they already have a name.

>>  Given the set_result and set_exception methods, it's pretty
>> straightforward to fill in the value of a future from something that isn't
>> purely computational.
>
> Those are described as "internal" methods in the PEP; by contrast, the
> Deferred equivalents are part of the public API.
>
>
>>  Given a way to register "on-done" callbacks with the future, it would be
>> straightforward to wait for a future without blocking, too.
>
> Yes, and with a few more additions besides that one, you might be on the way
> to an actual competitor for Deferreds.  For example: retry support,
> chaining, logging, API for transparent result processing, coroutine support,
> co-ordination tools like locks, sempaphores and queues, etc.
>
> These are all things you would very likely want or need if you actually
> wanted to write a program using futures as *your main computational model*,
> vs. just needing to toss out some parallel tasks in a primarily synchronous
> program.
>
> Of course, Deferreds are indeed overkill if all you're ever going to want is
> a few parallel tasks, unless you're already skilled in using Twisted or some
> wrapper for it.
>
> So, I totally support having a simple task queue in the stdlib, as there are
> definitely times I would've used such a thing for a quick script, if it were
> available.
>
> However, I've *also* had use cases for using futures as a computational
> model, and so that's what I originally thought this PEP was about.  After
> the use cases were clarified, though, it seems to me that *calling* it
> futures is a bad idea, because it's really just a nice task queuing system.
>
> I'm +1 on adding a nice task queuing system, -1 on calling it by any other
> name.  ;-)

So let's focus on the functionality of the task queuing system, and
stick to roughly the functionality proposed in the PEP.

The name is a non-issue and further discussion ought to be sent to
[email protected].

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] unittest2 plus class and module level fixtures in unittest

2010-03-07 Thread Michael Foord 

Hello all,

unittest has seen quite a few new features since Python 2.6. For those 
of you who might have missed the announcements in other places, 
unittest2 is a backport of the new features in unittest to work with 
Python 2.4-2.6. It is already being used for the development of distutils2:


http://pypi.python.org/pypi/unittest2/ 



In other news, class and module fixtures (setUpClass / tearDownClass / 
setUpModule / tearDownModule) are now implemented in unittest (in trunk 
- not yet merged to py3k). These features are tested but I'm sure there 
are some lurking bugs or oddities, so please try them out. I have not 
yet added documentation for them; I'll pull it out from this email as a 
starting point.


I'd rather this thread didn't become *another* debate on the merit of 
these features, but perhaps that is too much to hope for.


Below are some notes on how class and module fixtures work.

Class and module level fixtures are implemented in unittest.TestSuite. 
When the test suite encounters a test from a new class then 
tearDownClass from the previous class (if there is one) is called, 
followed by setUpClass from the new class.


Similarly if a test is from a different module from the previous test 
then tearDownModule from the previous module is run, followed by 
setUpModule from the new module.


After all the tests have run the final tearDownClass and tearDownModule 
are run.


Note that shared fixtures do not play well with [potential] features 
like test parallelization and they break test isolation. They should be 
used with care.



setUpClass and tearDownClass
--

These must be implemented as class methods.

import unittest

class Test(unittest.TestCase):
@classmethod
def setUpClass(cls):
cls._connection = createExpensiveConnectionObject()

@classmethod
def tearDownClass(cls):
cls._connection.destroy()

If you want the setUpClass and tearDownClass on base classes called then 
you must call up to them yourself. The implementations in 
unittest2.TestCase are empty.


If an exception is raised during a setUpClass then the tests in the 
class are not run and the tearDownClass is not run. Skipped classes will 
not have setUpClass or tearDownClass run.


A setUpClass that raises a unittest2.SkipTest exception will currently 
be reported as an error rather than a skip (although the effect is the 
same). This will be fixed at some point in the future.



setUpModule and tearDownModule


These should be implemented as functions.

def setUpModule():
createConnection()

def tearDownModule():
closeConnection()

If an exception is raised in a setUpModule then none of the tests in the 
module will be run and the tearDownModule will not be run.


A setUpModule that raises a unittest.SkipTest exception will currently 
be reported as an error rather than a skip (although the effect is the 
same). This will be fixed at some point in the future.



The Gory Details
--

The default ordering of tests created by the unittest test loaders is to 
group all tests from the same modules and classes together. This will 
lead to setUpClass / setUpModule (etc) being called exactly once per 
class and module. If you randomize the order, so that tests from 
different modules and classes are adjacent to each other, then these 
shared fixture functions may be called multiple times in a single test run.


This particular issue was a point of some disussion. Shared fixtures are 
not intended to work with suites with non-standard (incompatible) 
ordering (a BaseTestSuite still exists for frameworks that don't want to 
support shared fixtures), so this is already a pathological situation. 
There are a couple of things unittest could do in this situation:


1) Work out the best order to run the setUp and tearDowns, based on 
the position of the first and last test from each class / module in the 
suite.
2) Run setUp and tearDowns appropriately if consecutive tests are 
from different classes and modules.


If your setUps do unrelated things then strategy 1 will be the best one, 
but (so long as your setups are repeatable) 2 will be fine just slower. 
If your setups do related things, for example pushing large test 
datasets into the same database, then having multiple setups active 
before the corresponding teardowns have been run will actually do the 
wrong thing and your tests will be broken. In addition strategy 1 relies 
on unrolling the test suite and introspecting all tests prior to the 
run, not all custom test suites implementations support this.


Given that strategy 2 was substantially easier to implement, and less 
likely to cause broken test runs, that was what I went with. It is of 
course possible to add alternative strategies, plus the metadata to 
support them, if there proves t

Re: [Python-Dev] unittest2 plus class and module level fixtures in unittest

2010-03-07 Thread Antoine Pitrou 
Le Mon, 08 Mar 2010 00:51:02 +,
Michael Foord  a écrit :
> 
> In other news, class and module fixtures (setUpClass /
> tearDownClass / setUpModule / tearDownModule) are now implemented in
> unittest (in trunk 
> - not yet merged to py3k). These features are tested but I'm sure
> there are some lurking bugs or oddities, so please try them out. I
> have not yet added documentation for them; I'll pull it out from this
> email as a starting point.
> 
> I'd rather this thread didn't become *another* debate on the merit of 
> these features, but perhaps that is too much to hope for.

Just for the record, could you sum up the reasons why you/we decided on
this route rather than e.g. adding a test-resources-like facility?

(I'm not saying I disagree, it's just that I didn't remember a decision
had already been made on this point)

Thanks for all your work on this!

cheers

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] unittest2 plus class and module level fixtures in unittest

2010-03-07 Thread Mark Roddy 
 On Sun, Mar 7, 2010 at 8:11 PM, Antoine Pitrou  wrote:
> Le Mon, 08 Mar 2010 00:51:02 +,
> Michael Foord  a écrit :
>>
>> In other news, class and module fixtures (setUpClass /
>> tearDownClass / setUpModule / tearDownModule) are now implemented in
>> unittest (in trunk
>> - not yet merged to py3k). These features are tested but I'm sure
>> there are some lurking bugs or oddities, so please try them out. I
>> have not yet added documentation for them; I'll pull it out from this
>> email as a starting point.
>>
>> I'd rather this thread didn't become *another* debate on the merit of
>> these features, but perhaps that is too much to hope for.
>
> Just for the record, could you sum up the reasons why you/we decided on
> this route rather than e.g. adding a test-resources-like facility?
>
> (I'm not saying I disagree, it's just that I didn't remember a decision
> had already been made on this point)
>
> Thanks for all your work on this!
>
> cheers
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/markroddy%40gmail.com
>


There were some lengthy threads on python-ideas
(http://mail.python.org/pipermail/python-ideas/2010-January/006736.html)
and python-dev 
(http://mail.python.org/pipermail/python-dev/2010-February/097521.html).

I'm sure Michael has a set of factors that are most important to him
for the decision (which I don't blame him for not wanting to get into,
the two previous threads were contentious), but for me personally I
don't view class/module setup and test-resources as necessarily
competing options.  For the simplest use case ( create some expensive
connection and/or object which is essentially stateless and won't need
to be torn down), I personally find a test-resources solution to
require an unnecessary amount of work to implement.  After exploring
it a bit in the course of those discussions I hope that test-resources
(or something similar, maybe something like junit rules which was also
brought up) makes it into the stdlib at some point as some of the more
complicated integration/scenario tests I support would be made much
simpler with such functionality.

-Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com