Re: [Python-Dev] argparse ugliness
On 7 Mar 2010, at 19:49, Guido van Rossum wrote:
How would you write the example instead then?
Boolean flags are a common enough case that I'd be inclined to add a wrapper
method, so you could just say:
parser.add_bool_argument('--plot')
As you can always fall back to the more general add_argument() call, the
wrapper could just handle the usual case (default false, presence of option
sets flag to True). So the signature would be pretty simple - something like:
def add_bool_argument(self, help=None, dest=None):
Mark Russell
___
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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
P.J. Eby wrote: I'm +1 on adding a nice task queuing system, -1 on calling it by any other name. ;-) As Guido said, let's call the nice task queuing system futures and point people wanting a full-power asynchronous process model to Twisted - while the Deferred API may technically be independent of the rest of the framework, you need at least some of the other tools for asynchronous operations to make it really shine. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
Dj Gilcrease wrote: On Sun, Mar 7, 2010 at 6:50 AM, Jesse Noller jnol...@gmail.com 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 Wouldn't a factory function serve that purpose just as well? Or even just from concurrent.futures import ProcessPoolExecutor as TaskExecutor. That last form has the virtue that you can retrieve your executor from anywhere rather than being limited to the two provided by the concurrent.futures model. I think the string based approach actually unduly constrains the API despite superficially appearing to make it more flexible. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Catch SIGINT at Python startup
Hi, I wrote patches for the issue #3137 and I would like your opinion about my solution (not directly about the patches): I propose to consider a SIGINT during startup as a fatal error. If you press CTRL+c while Python is starting, Python displays an error and exit with the code 1. Currently, if you press CTRL+c while Python is starting: the SIGINT signal will be *ignored* somewhere between Python initialization and the first Python instruction. First problem is that if site import is interrupted, Python is not completly initialized (if a SIGINT is sent just after the call to initsigs(), initsite() is completly skipped). Example: -- $ python ^C Traceback (most recent call last): File /home/SHARE/SVN/python-trunk/Lib/site.py, line 62, in module import os File /home/SHARE/SVN/python-trunk/Lib/os.py, line 44, in module from posix import * KeyboardInterrupt $ echo $? 1 -- It's not easy to reproduce this issue because Python initialization is really fast (yeah really! or at least to fast for me ;-)). I'm using valgrind --log- file=/dev/null ./python -v to simulate a very slow computer :-) -- Victor Stinner http://www.haypocalc.com/ ___ 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
Re: [Python-Dev] argparse ugliness
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@gmail.com 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?
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard steven.beth...@gmail.com wrote:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@gmail.com 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?
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Sorry, that should have been:
parser.add_argument('--plot', action=argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@gmail.com wrote:
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions
...
parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
On 3/8/2010 6:14 AM, Nick Coghlan wrote: P.J. Eby wrote: I'm +1 on adding a nice task queuing system, -1 on calling it by any other name. ;-) As Guido said, let's call the nice task queuing system futures and I was confused by 'futures' also until Philip explained it as task-queue or task-pool, and hence also do not like it. Since the examples in the PEP do *NOT* give example output, it was not clear to me whether execution or the termination thereof is ordered (queue) or not (pool). Looking more close, I gather that the prime results will be printed 'in order' (waiting on each even if others are done) while the url results will be printed 'as available'. Adding 'will print ...' and 'might print ...' outputs would help. point people wanting a full-power asynchronous process model to Twisted That could be done in the PEP to clarify its scope. Terry Jan Reedy ___ 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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
On 3/6/2010 4:20 AM, Brian Quinlan wrote: On 6 Mar 2010, at 03:21, Daniel Stutzbach wrote: On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com mailto:br...@sweetapp.com 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 thoug ht about that but this discussion is spread over many threads and many months. This is pretty typical. I would say just that, and link to the first. This PEP was discussed over many months in many threads in the stdlib-sig list. The first was . Python-dev discussion occured in this thread. tjr ___ 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
Re: [Python-Dev] argparse ugliness
On Monday 08 March 2010, David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@gmail.com wrote:
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions
...
parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
+1
___
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
Re: [Python-Dev] argparse ugliness
On 8 Mar 2010, at 16:53 , David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@gmail.com wrote:
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions
...
parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
action is taken from **kwargs, not from a positional argument as *args
is a sequence of option strings (so you can write
add_argument('-p', '/p', '--plot', '--land-mass')). So you'd have to write
add_argument('--plot', action=actions.store_true) which is straight from
the department of redundant redundancies.
An option would be
parser.add(actions.StoreTrue('--plot'))
but I'm not sure this makes any sense API-wise, and it would probably make
the code a lot messier as the parser would have to reach into the action
to get the information it needs. Either that, or the action would be an *arg
and argparse would have to walk all of its *args type-testing each one to find
if there's an action anywhere.
___
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
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 11:49 AM, Xavier Morel python-...@masklinn.net wrote:
On 8 Mar 2010, at 16:53 , David Stanek wrote:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@gmail.com wrote:
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
Any reason not to do something like:
from argparse import actions
...
parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
action is taken from **kwargs, not from a positional argument as *args
is a sequence of option strings (so you can write
add_argument('-p', '/p', '--plot', '--land-mass')). So you'd have to write
add_argument('--plot', action=actions.store_true) which is straight from
the department of redundant redundancies.
An option would be
parser.add(actions.StoreTrue('--plot'))
but I'm not sure this makes any sense API-wise, and it would probably make
the code a lot messier as the parser would have to reach into the action
to get the information it needs. Either that, or the action would be an *arg
and argparse would have to walk all of its *args type-testing each one to find
if there's an action anywhere.
You could just change my example to:
from argparse.actions import store_true
...
parser.add_argument('--plot', action=store_true)
I would probably still import the actions namespace directly, but
wouldn't have to.
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
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
Re: [Python-Dev] Catch SIGINT at Python startup
On 08/03/2010 13:12, Victor Stinner wrote: Hi, I wrote patches for the issue #3137 and I would like your opinion about my solution (not directly about the patches): I propose to consider a SIGINT during startup as a fatal error. If you press CTRL+c while Python is starting, Python displays an error and exit with the code 1. That sounds like a good solution to me. +1 Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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
Re: [Python-Dev] argparse ugliness
Steven Bethard wrote:
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard steven.beth...@gmail.com wrote:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum gu...@python.org wrote:
On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker ndbeck...@gmail.com wrote:
Brian Curtin wrote:
On Fri, Mar 5, 2010 at 12:51, Neal Becker ndbeck...@gmail.com 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?
In argparse, unlike optparse, actions are actually defined by objects
with a particular API, and the string is just a shorthand for
referring to that. So:
parser.add_argument ('--plot', action='store_true')
is equivalent to:
parser.add_argument('--plot', argparse._StoreTrueAction)
Sorry, that should have been:
parser.add_argument('--plot', action=argparse._StoreTrueAction)
Because the names are so long and you'd have to import them, I've left
them as private attributes of the module, but if there's really
demand, we could rename them to argparse.StoreTrueAction, etc.
I like the strings. They are simple and easy to use/read and they don't
have to be created or imported before the parser is defined. That allows
me to put the parser setup right after the 'if __name__ == '__main__':' so
it's easy to find and read. It also allows me to not import or create
objects that may be expensive in either time or resources if I'm not going
to use them.
Also the strings help separate the parser from the rest of your program in
a much cleaner way. This can make your programs more modular and easier to
modify and maintain.
Ron
___
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
Re: [Python-Dev] Catch SIGINT at Python startup
Actually it sounds like there's some overly general except clause somewhere that should be adjusted to catch just Exception instead of *. On Mon, Mar 8, 2010 at 9:14 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 08/03/2010 13:12, Victor Stinner wrote: Hi, I wrote patches for the issue #3137 and I would like your opinion about my solution (not directly about the patches): I propose to consider a SIGINT during startup as a fatal error. If you press CTRL+c while Python is starting, Python displays an error and exit with the code 1. That sounds like a good solution to me. +1 Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] argparse ugliness
On Mon, Mar 8, 2010 at 9:17 AM, Ron Adam r...@ronadam.com wrote: I like the strings. They are simple and easy to use/read and they don't have to be created or imported before the parser is defined. I like them too. I don't see anything unpythonic about them. That allows me to put the parser setup right after the 'if __name__ == '__main__':' so it's easy to find and read. It also allows me to not import or create objects that may be expensive in either time or resources if I'm not going to use them. Also the strings help separate the parser from the rest of your program in a much cleaner way. This can make your programs more modular and easier to modify and maintain. Also in this particular case a typo in the string will be caught just about at the same time as a typo in the name would be caught. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Catch SIGINT at Python startup
On Mon, Mar 8, 2010 at 10:47 AM, Guido van Rossum gu...@python.org wrote: Actually it sounds like there's some overly general except clause somewhere that should be adjusted to catch just Exception instead of *. There is at least one that prints import 'site' failed and continues to run your program. Cheers, fijal ___ 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
Re: [Python-Dev] Catch SIGINT at Python startup
On Mon, Mar 8, 2010 at 10:21 AM, Maciej Fijalkowski fij...@gmail.com wrote: On Mon, Mar 8, 2010 at 10:47 AM, Guido van Rossum gu...@python.org wrote: Actually it sounds like there's some overly general except clause somewhere that should be adjusted to catch just Exception instead of *. There is at least one that prints import 'site' failed and continues to run your program. Yeah, it shouldn't do that. The ^C should fall through. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
On Mon, Mar 8, 2010 at 4:25 AM, Nick Coghlan ncogh...@gmail.com wrote: Wouldn't a factory function serve that purpose just as well? Or even just from concurrent.futures import ProcessPoolExecutor as TaskExecutor. That last form has the virtue that you can retrieve your executor from anywhere rather than being limited to the two provided by the concurrent.futures model. I think the string based approach actually unduly constrains the API despite superficially appearing to make it more flexible. mm you are correct, I went with the string approach because I was experimenting with 3 additional executor types and wanted to be able to switch between or intermix them them without having to change imports and didnt feel like writing a register class with a factory method. A style I have used in my own code in the past is a Singleton class with register and create methods, where the register takes a name(string) and the class and the create method takes the name and *args, **kwargs and acts as a factory. Would this style be better or would it be better to just leave it with the two executor classes? I tend to dislike multiple classes for a what is essentially a Strategy of a concept and factories are something I tend to forget about until well after my initial idea has formed into a proof of concept. ___ 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
Re: [Python-Dev] unittest2 plus class and module level fixtures in unittest
On 08/03/2010 01:11, Antoine Pitrou wrote: Le Mon, 08 Mar 2010 00:51:02 +, Michael Foordfuzzy...@voidspace.org.uk 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) Well, Guido had already stated on python-ideas that he wanted these features (class and module fixtures) in unittest. I (and others) suggested testresources as an alternative but it became clear that it didn't offer a suitable abstraction for module level fixtures, instead you would have to manually attach the resources to all of the classes in the module yourself. In addition to the lack of a module level fixture abstraction Guido felt that the testresources API itself was not yet mature or polished enough to come into the standard library. At that point I figured we had reverted to the decision that setUpClass / setUpModule should go in. testresources still works of course, and is a better general solution for shared fixtures where people are pushing beyond what setUpClass and setUpModule allow. I'll probably link to testresources in the shared fixture documentation - and it has the great advantage of *not* being in the standard library and is therefore free to evolve faster. All the best, Michael Thanks for all your work on this! cheers Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Building thread-safe sqlite3 with Python 2.6.5rc1
Hi, I'm trying to get the thread-safe enabled for sqlite3 in my build of 2.6.5rc1, but its not taking and throws the old thread access error. I am running Ubuntu with other versions of Python, but I successfully built and installed sqlite 3.6.22, pysqlite 2.6.0. Do I have to set something explicit when building python 2.6.5 to find the updated sqlite3? thanks for any tips. Darren ___ 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
Re: [Python-Dev] Catch SIGINT at Python startup
Hi, Le lundi 08 mars 2010 18:47:18, Guido van Rossum a écrit : Actually it sounds like there's some overly general except clause somewhere that should be adjusted to catch just Exception instead of *. Most of my patches (for SIGINT) are exactly doing that: check the exception type instead of if (result == NULL) PyErr_Clear(); (try/except: pass). About initsite(): I consider any error as fatal. If initsite() failed, something goes wrong. I think that my patches are enough to catch SIGINT during the Python initialization. I used different tricks to test Python: add kill(getpid(), SIGINT), use signal SIGINT in gdb, add PyErr_SetNone(PyExc_KeyboardInterrupt), ... valgrind is a very good tool to slow down any process :-D -- Victor Stinner http://www.haypocalc.com/ ___ 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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
I'm +1 on adding a nice task queuing system, -1 on calling it by any other name. ;-) Nick As Guido said, let's call the nice task queuing system futures Nick and point people wanting a full-power asynchronous process model Nick to Twisted Can this module at least be pushed down into a package? I think concurrent or concurrency were both suggested at one point. Skip ___ 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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease digitalx...@gmail.com wrote: A style I have used in my own code in the past is a Singleton class with register and create methods, where the register takes a name(string) and the class and the create method takes the name and *args, **kwargs and acts as a factory. So I decided to play with this design a little and since I made it a singleton I decided to place all the thread/process tracking and exit handle code in it instead of having the odd semi-global scoped _shutdown, _thread_references, _remove_dead_thread_references and _python_exit objects floating around in each executor file, seems to work well. The API would be from concurrent.futures import executors executor = executors.create(NAME, *args, **kwargs) # NAME is 'process' or 'thread' by default To create your own executor you create your executor class and add the following at the end from concurrent.futures import executors, ExecutorBase class MyExecutor(ExecutorBase): ... executors.register(NAME, MyExecutor) It checks to see if your executor is a subclass of ExecutorBase, but only does a UserWarning if it is not since you should know what methods are required to be an executor like object, so if you are not subclassing ExecutorBase you should suppress the UserWarning before you register you class and un-suppress it after Some Helper Methods/Properties on the executors Singleton add_joinable_ref - This replaces the _thread_references.add system of tracking threads, and it allows for adding processes as well hence the joinable_ref name. It does check to make sure the ref being passes has a join method then creates a weakref to it and adds it to a set. For every thread or process your executor creates you should call this with so it will be tracked properly cleanup_joinable_refs - This replaces the _remove_dead_thread_references that had to be written for each executor individually. This should be called periodically, currently it is only called when you create a new executor since it is a blocking method (it uses a thread lock to make sure the set of references does not change while it is discarding old ones) shutdown - is a readonly property and replaces the _shutdown global var that had to be created for each executor individually, it is set in the executors destructor __del__ - replaces the _python_exit method that had to be written for each executor individually If this API change isnt accepted its no big deal, since I am only changing it due to personal pet peeves and the only real issue I had with the package was scoping which has already been addressed by adding it to a concurrent package ___ 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
Re: [Python-Dev] Catch SIGINT at Python startup
On Mon, Mar 8, 2010 at 12:50 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Le lundi 08 mars 2010 18:47:18, Guido van Rossum a écrit : Actually it sounds like there's some overly general except clause somewhere that should be adjusted to catch just Exception instead of *. Most of my patches (for SIGINT) are exactly doing that: check the exception type instead of if (result == NULL) PyErr_Clear(); (try/except: pass). About initsite(): I consider any error as fatal. If initsite() failed, something goes wrong. I think that my patches are enough to catch SIGINT during the Python initialization. I used different tricks to test Python: add kill(getpid(), SIGINT), use signal SIGINT in gdb, add PyErr_SetNone(PyExc_KeyboardInterrupt), ... valgrind is a very good tool to slow down any process :-D I see. I thought for a moment that by fatal you meant something like calling Py_FatalError(). I am trying to remember why I made site.py failures non-fatal in the first place. I don't have any specific recollection but it must've been either from before the separation between site.py (part of the stdlib) and sitecustomize.py (site-specific) or out of a worry that if some external cause broke site.py (which does a lot of I/O) it would be a fatal breakdown of all Python execution. I am fine with making an exception for KeyboardInterrupt (and other exceptions not deriving from Exception but only from BaseException) but I don't think I want to go as far as making all errors coming out of site.py fatal. (At least not without more understanding of the use case for making these non-fatal in the first place.) OTOH I think the try/except in site.py around the execution of sitecustomize.py might be changed so that it prints a full traceback whenever it raises an exception other than ImportError or, again, exceptions inheriting from BaseException but not from Exception. IOW I think that exceptions coming out of sitecustomize.py should continued to be treated non-fatally, apart from ^C and friends, but I think that exceptions coming out of site.py *might* be considered more fatally once the change to exceptions coming out of sitecustomize.py is made. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] argparse ugliness
Mark Russell wrote:
Boolean flags are a common enough case that I'd be inclined to add a wrapper
method,
parser.add_bool_argument('--plot')
+1, this looks good.
--
Greg
___
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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
On 08:56 pm, digitalx...@gmail.com wrote: On Mon, Mar 8, 2010 at 12:04 PM, Dj Gilcrease digitalx...@gmail.com wrote: A style I have used in my own code in the past is a Singleton class with register and create methods, where the register takes a name(string) and the class and the create method takes the name and *args, **kwargs and acts as a factory. So I decided to play with this design a little and since I made it a singleton I decided to place all the thread/process tracking and exit handle code in it instead of having the odd semi-global scoped _shutdown, _thread_references, _remove_dead_thread_references and _python_exit objects floating around in each executor file, seems to work well. The API would be from concurrent.futures import executors executor = executors.create(NAME, *args, **kwargs) # NAME is 'process' or 'thread' by default To create your own executor you create your executor class and add the following at the end Getting rid of the process-global state like this simplifies testing (both testing of the executors themselves and of application code which uses them). It also eliminates the unpleasant interpreter shutdown/module globals interactions that have plagued a number of stdlib systems that keep global state. Jean-Paul ___ 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
Re: [Python-Dev] Catch SIGINT at Python startup
On Mar 8, 2010, at 4:06 PM, Guido van Rossum wrote: I am trying to remember why I made site.py failures non-fatal in the first place. I don't have any specific recollection but it must've been either from before the separation between site.py (part of the stdlib) and sitecustomize.py (site-specific) or out of a worry that if some external cause broke site.py (which does a lot of I/O) it would be a fatal breakdown of all Python execution. The thing that occurs to me is that one might want to write an administrative tool in Python to manipulate site.py, or even just some data that something in site.py would load. If exceptions from site.py were fatal, then bugs in such a tool would be completely unrecoverable; in trying to run it to un-do the buggy operation, it would crash immediately. On the other hand, such a tool should *really* be invoked with the -S option anyway, so... maybe not that pressing of a concern. ___ 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
Re: [Python-Dev] argparse ugliness
Steven Bethard wrote: Because the names are so long and you'd have to import them, I've left them as private attributes of the module, but if there's really demand, we could rename them to argparse.StoreTrueAction, etc. What's wrong with just StoreTrue? -- Greg ___ 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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
Terry Reedy wrote: Looking more close, I gather that the prime results will be printed 'in order' (waiting on each even if others are done) while the url results will be printed 'as available'. Seems to me that if you care about the order of the results, you should be able to just wait for each result separately in the order you want them. Something like task1 = start_task(proc1) task2 = start_task(proc2) task3 = start_task(proc3) result1 = task1.wait_for_result() result2 = task2.wait_for_result() result3 = task3.wait_for_result() This would also be a natural way to write things even if you don't care about the order, but you need all the results before proceeding. You're going to be held up until the longest-running task completes anyway, so it doesn't matter if some of them finish earlier and have to sit around waiting for you to collect the result. -- Greg ___ 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
Re: [Python-Dev] argparse ugliness
On 2010-03-08 15:20 PM, Greg Ewing wrote:
Mark Russell wrote:
Boolean flags are a common enough case that I'd be inclined to add a
wrapper method,
parser.add_bool_argument('--plot')
+1, this looks good.
I've added it to the argparse bugtracker, along with my suggested spelling
add_flag():
http://code.google.com/p/argparse/issues/detail?id=62
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth.
-- Umberto Eco
___
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
Re: [Python-Dev] argparse ugliness
Xavier Morel wrote:
So you'd have to write
add_argument('--plot', action=actions.store_true) which is straight from
the department of redundant redundancies.
This could easily be fixed with
from argparse.actions import store_true
An option would be
parser.add(actions.StoreTrue('--plot'))
but I'm not sure this makes any sense API-wise, and it would probably make
the code a lot messier as the parser would have to reach into the action
to get the information it needs.
It would make more sense if the object concerned were called
an Option or some such instead of an Action:
parser.add(options.Bool('--plot'))
--
Greg
___
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
Re: [Python-Dev] Catch SIGINT at Python startup
On Mon, Mar 8, 2010 at 1:18 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote: On Mar 8, 2010, at 4:06 PM, Guido van Rossum wrote: I am trying to remember why I made site.py failures non-fatal in the first place. I don't have any specific recollection but it must've been either from before the separation between site.py (part of the stdlib) and sitecustomize.py (site-specific) or out of a worry that if some external cause broke site.py (which does a lot of I/O) it would be a fatal breakdown of all Python execution. The thing that occurs to me is that one might want to write an administrative tool in Python to manipulate site.py, or even just some data that something in site.py would load. This would be a more likely theory if we didn't have sitecustomize.py to be manipulated. If exceptions from site.py were fatal, then bugs in such a tool would be completely unrecoverable; in trying to run it to un-do the buggy operation, it would crash immediately. On the other hand, such a tool should *really* be invoked with the -S option anyway, so... maybe not that pressing of a concern. Right. I'm leaning towards the theory that treating site.py failures as non-fatal is older than the separation between site.py and sitecustomize.py. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Catch SIGINT at Python startup
Le lundi 08 mars 2010 22:18:34, Glyph Lefkowitz a écrit : On Mar 8, 2010, at 4:06 PM, Guido van Rossum wrote: I am trying to remember why I made site.py failures non-fatal in the first place. I don't have any specific recollection but it must've been either from before the separation between site.py (part of the stdlib) and sitecustomize.py (site-specific) or out of a worry that if some external cause broke site.py (which does a lot of I/O) it would be a fatal breakdown of all Python execution. The thing that occurs to me is that one might want to write an administrative tool in Python to manipulate site.py, or even just some data that something in site.py would load. If exceptions from site.py were fatal, then bugs in such a tool would be completely unrecoverable; in trying to run it to un-do the buggy operation, it would crash immediately. I don't think that modifying the site.py file is a good idea. Why not editing/generating the sitecustomize or usercustomize module? Anyway, if you write such tool: use a different language or use a failsafe Python interpreter dedicated to this tool ;-) -- Victor Stinner http://www.haypocalc.com/ ___ 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
Re: [Python-Dev] Building thread-safe sqlite3 with Python 2.6.5rc1
thanks for any tips. Set sqlite_setup_debug to True in setup.py Regards, Martin ___ 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
Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
Dj Gilcrease wrote: executor = executors.create(NAME, *args, **kwargs) # NAME is 'process' or 'thread' by default from concurrent.futures import executors, ExecutorBase class MyExecutor(ExecutorBase): ... executors.register(NAME, MyExecutor) I don't understand the reason for using a registration system rather than just importing names from a module. You mentioned wanting to globally change the executor class being used by a program without having to make changes throughout. Registering a different class under the same name would be one way to do that, but you could achieve the same thing just by assigning to a name in a module. In other words, instead of inventing your own mechanism for managing a namespace, just use a module as your namespace. -- Greg ___ 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
Re: [Python-Dev] argparse ugliness
David Stanek dsta...@dstanek.com writes:
On Mon, Mar 8, 2010 at 10:40 AM, Steven Bethard
steven.beth...@gmail.com wrote:
parser.add_argument ('--plot', action='store_true')
[…]
+1.
Any reason not to do something like:
from argparse import actions
...
parser.add_argument('--plot', actions.store_true)
Basically a small namespace for the constants.
-1.
That ignores the value to the programmer in specifying keyword arguments
(there are a lot of arguments to the function, making keyword arguments
a better mean-what-you-say choice). To be equivalent, it would have to
be:
from argparse import actions
# ...
parser.add_argument('--plot', action=actions.store_true)
I prefer the string values.
--
\ “Value your freedom or you will lose it, teaches history. |
`\ “Don't bother us with politics,” respond those who don't want |
_o__) to learn.” —Richard Stallman, 2002 |
Ben Finney
___
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
Re: [Python-Dev] Catch SIGINT at Python startup
Le lundi 08 mars 2010 22:06:36, vous avez écrit : OTOH I think the try/except in site.py around the execution of sitecustomize.py might be changed so that it prints a full traceback whenever it raises an exception other than ImportError or, again, exceptions inheriting from BaseException but not from Exception. IOW I think that exceptions coming out of sitecustomize.py should continued to be treated non-fatally, apart from ^C and friends, but I think that exceptions coming out of site.py *might* be considered more fatally once the change to exceptions coming out of sitecustomize.py is made. Do you mean something like the following code? -- def execsitecustomize(): Run custom site specific code, if available. try: import sitecustomize except ImportError: pass except Exception: if sys.flags.verbose: sys.excepthook(*sys.exc_info()) else: print sys.stderr, 'import sitecustomize' failed; use -v for traceback def execusercustomize(): Run custom user specific code, if available. try: import usercustomize except ImportError: pass except Exception: if sys.flags.verbose: sys.excepthook(*sys.exc_info()) else: print sys.stderr, 'import usercustomize' failed; use -v for traceback -- Using these functions, even if sitecustomize fails, usercustomize is imported. Can it be a problem? Does usercustomize requires that sitecustomize has been initialized correctly? (The code can be changed to only import usercustomize if sitecutomize succeed or failed with an ImportError, but not if it fails with a different error) -- Victor Stinner http://www.haypocalc.com/ ___ 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
Re: [Python-Dev] Catch SIGINT at Python startup
On Mon, Mar 8, 2010 at 2:01 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Le lundi 08 mars 2010 22:06:36, vous avez écrit : OTOH I think the try/except in site.py around the execution of sitecustomize.py might be changed so that it prints a full traceback whenever it raises an exception other than ImportError or, again, exceptions inheriting from BaseException but not from Exception. IOW I think that exceptions coming out of sitecustomize.py should continued to be treated non-fatally, apart from ^C and friends, but I think that exceptions coming out of site.py *might* be considered more fatally once the change to exceptions coming out of sitecustomize.py is made. Do you mean something like the following code? -- def execsitecustomize(): Run custom site specific code, if available. try: import sitecustomize except ImportError: pass except Exception: if sys.flags.verbose: sys.excepthook(*sys.exc_info()) else: print sys.stderr, 'import sitecustomize' failed; use -v for traceback def execusercustomize(): Run custom user specific code, if available. try: import usercustomize except ImportError: pass except Exception: if sys.flags.verbose: sys.excepthook(*sys.exc_info()) else: print sys.stderr, 'import usercustomize' failed; use -v for traceback -- Yes, roughly. Using these functions, even if sitecustomize fails, usercustomize is imported. Until 5 minutes ago I didn't even know we had usercustomize. :-) Can it be a problem? Does usercustomize requires that sitecustomize has been initialized correctly? I don't know, but if it is, execsitecustomize() could return a flag to be checked by the code that calls execusercustomize(). (The code can be changed to only import usercustomize if sitecutomize succeed or failed with an ImportError, but not if it fails with a different error) Right. It doesn't strike me as a big deal either way. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Building thread-safe sqlite3 with Python 2.6.5rc1
Thanks. It says. sqlite: found /usr/local/include/sqlite3.h /usr/local/include/sqlite3.h: version 3.6.22 Which is correct. Yet when I run my progam using the newly built python executable and attempt to use sqlite3 functionality across threads it still says: ProgrammingError: SQLite objects created in a thread can only be used in that same thread.The object was created in thread id -1217128768 and this is thread id -1218753680 I set the -DSQLITE_THREADSAFE=1 flag on sqlite3 when I configured, built and installed the lib. Darren On Mon, 2010-03-08 at 22:52 +0100, Martin v. Löwis wrote: thanks for any tips. Set sqlite_setup_debug to True in setup.py Regards, Martin ___ 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
Re: [Python-Dev] Building thread-safe sqlite3 with Python 2.6.5rc1
Which is correct. Yet when I run my progam using the newly built python executable and attempt to use sqlite3 functionality across threads it still says: ProgrammingError: SQLite objects created in a thread can only be used in that same thread.The object was created in thread id -1217128768 and this is thread id -1218753680 I set the -DSQLITE_THREADSAFE=1 flag on sqlite3 when I configured, built and installed the lib. So you'll need to run Python in a debugger, trying to find out under what conditions the exception is raised. This kind of question is off-topic for python-dev (which is about development of Python, not about using it). Regards, Martin ___ 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
Re: [Python-Dev] Building thread-safe sqlite3 with Python 2.6.5rc1
On Mon, Mar 08, 2010 at 05:28:10PM -0500, Darren Govoni wrote: ProgrammingError: SQLite objects created in a thread can only be used in that same thread.The object was created in thread id -1217128768 and this is thread id -1218753680 Darren, try to pass check_same_thread=False when creating a connection. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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
