Re: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
On Mon, Feb 21, 2011 at 1:52 PM, Nick Coghlan ncogh...@gmail.com wrote: As the subject line asks, is there anything preventing the following PEPs from being marked Final? SA 389 argparse - New Command Line Parsing Module Bethard Sorry for taking forever to get back to this. So I looked over PEP 389 and it's basically complete, but I never implemented the code deprecation warnings for optparse (only the documentation deprecation warnings). The PEP claims: Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued. Python 3.2+ -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. I'm kind of inclined to just remove those lines from the PEP since optparse is not being removed and since 2.7 and 3.2 are already out the door. If anyone thinks those deprecation warnings really need to be implemented, let me know in the next couple days. Otherwise, I'll update the PEP and mark it as final. 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
[Python-Dev] okay to remove argparse.__all__?
I think the easiest and most sensible way to address http://bugs.python.org/issue9353 is to simply remove the __all__ definition from argparse - everything that doesn't start with an underscore in the module is already meant to be exposed. But then I wonder - is __all__ considered part of the public API of a module? Or is it okay to just remove it and assume that no one should have been accessing it directly anyway? 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] okay to remove argparse.__all__?
On Mon, Nov 1, 2010 at 2:53 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 01/11/2010 14:48, Steven Bethard wrote: I think the easiest and most sensible way to address http://bugs.python.org/issue9353 is to simply remove the __all__ definition from argparse - everything that doesn't start with an underscore in the module is already meant to be exposed. But then I wonder - is __all__ considered part of the public API of a module? Or is it okay to just remove it and assume that no one should have been accessing it directly anyway? Isn't it better to add the missing elements - what is the problem with that approach? It just requires extra synchronization, and history shows that I always forget to add them. ;-) Not defining __all__ will mean that from argparse import * will also export all the modules you import (copy, os, re, sys, textwrap). That won't happen in the case of argparse - all modules are imported like import os as _os. 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] okay to remove argparse.__all__?
On Mon, Nov 1, 2010 at 2:57 PM, Guido van Rossum gu...@python.org wrote: On Mon, Nov 1, 2010 at 7:53 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 01/11/2010 14:48, Steven Bethard wrote: But then I wonder - is __all__ considered part of the public API of a module? Or is it okay to just remove it and assume that no one should have been accessing it directly anyway? Isn't it better to add the missing elements - what is the problem with that approach? Agreed, that's what I would do. Ok, sounds good. It is also possible to write automated tests that flag likely missing symbols in __all__ (as well as symbols in __all__ missing from the module). Yep, I plan on doing that. I already had a test something like this to remind me how I broke __all__ before. ;-) 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] [Python-checkins] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst
On Tue, Sep 21, 2010 at 3:46 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I agree. Don't feel strongly about it though. (I'm sure Strunk and White would disapprove.) No doubt. http://chronicle.com/article/50-Years-of-Stupid-Grammar/25497 ;-) 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
[Python-Dev] moving issues from argparse tracker to python tracker?
Before I go and add about 30 open issues to the Python tracker, I figured I should ask. What's the normal process for the bug trackers of modules that move to the standard library? I have a few feature requests, etc. for argparse, and I was planning to just copy them over to the Python bug tracker (and close them on the Google code tracker). Is this what people normally do? (It should be easy enough to do - I just don't want to mess up the tracker if this is usually done some other way.) Thanks, 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
[Python-Dev] bug or feature? fixing argparse's default help value for version actions
Sorry I haven't had time to get around to the argparse issues. I
should have time this weekend. I need a release manager call on one of
the issues though. Two things I assume are fine to fix at this stage:
* In the documentation, the '--version' example should either not use
a shorthand, or should use the conventional '-V'
* In the documentation, the difference between the argparse and
optparse ways of specifying versions needs to be mentioned in the
section on migrating from optparse.
One thing I'm not sure about:
* Right now, the default help value for the version action is None,
which is pretty useless since it means that everyone has to type in
the same help=show program's version number and exit when they use
the version action. Instead, the string show program's version number
and exit should have been the default value for the help argument. To
be explicit, right now everyone who adds a version to their argument
parser has to write:
parser.add_argument('-V', action='version', version='the version',
help=show program's version number and exit)
With the fixed default value you would only have to write:
parser.add_argument('-V', action='version', version='the version')
Can this be considered a bug, i.e. something that can be committed
before the RC? Or does it need to be considered a feature, i.e. at
this point can never be added to Python 2.7?
Thanks, and sorry again for not having time for this until now,
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 ambiguity handling
On Wed, Apr 21, 2010 at 2:14 AM, Jon Ribbens jon+python-...@unequivocal.co.uk wrote: On Wed, Apr 21, 2010 at 03:53:16AM -0400, Eric Smith wrote: I agree the new behavior is desirable. And I also think it should be the default, although I feel less strongly about that. But since this behavior seems to be an accident of the implementation (based on Steve's comment above), I think a test should be added for it if it's accepted as a Good Thing (tm). Otherwise it's possible that it will vanish as the implementation changes. +1 to all of that Turns out I actually fixed this on purpose in r79 of argparse, and even added a test (TestOptionalsDoubleDashPrefixMatch) to test this behavior. So also +1 from me as well since I've already done it. ;-) 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 ambiguity handling
On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker ndbeck...@gmail.com wrote: I've noticed argparse ambiguity handling has changed a bit over last few revisions. I have cases where 1 valid input is a prefix of another: e.g.: '--string' '--string2' With the most recent 1.1, the behavior is: --string=hello is accepted, while: --strin=hello is marked as ambiguous. I'm OK with this, but just want to know if there is agreement that this is the behavior we want. I don't have a strong feeling about this. What was the behavior before? 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] Python 2.7b1 and argparse's version action
On Mon, Apr 19, 2010 at 12:51 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: On 19/04/2010 21:19, Scott Dial wrote: Is consensus superficial? No, but it isn't always possible or necessary. In general the maintainer of a module should make the best decision, not the one with the most backing. :-) Yep, that was my logic. With 42% vs. 47% I decided there really wasn't consensus, and I should make the decision that I felt was best for argparse. If it had been e.g., 20% vs 80%, I would have bent to the will of the masses regardless of what I thought. 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] Python 2.7b1 and argparse's version action
On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp tobias.h...@gmx.de wrote:
To put it short:
*Argparse should simply do this like optparse does already.*
I.e., use '--version', '--help' and '-h' by default, but not '-v'.
[snip]
What happened was the following:
Completely unnecessarily, the 'version' constructor argument is now
deprecated.
[snip]
The deprecation of the 'version' argument press-gangs people to replace
it by
parser.add_argument('--version', action='version',
version='the version', # the only common part
help=show program's version number and exit)
What Tobias has conveniently omitted is that there was not much
agreement on what the default behavior of the version flag should be.
Things that were proposed:
* Use both -v and --version
* Use both -V and --version
* Use just --version
* Print out just the version string
* Print out program name with the version string
I put up a poll and asked people for feedback on some of the alternatives:
http://www.vizu.com/res/Grab-bag/argparse/poll-results.html?n=192933
And it was far from a consensus. Given the lack of consensus, the many
different options people thought were the right way to do things,
and the fact that the action='version' approach allows people to
customize the flags to whatever they want, I stick by my decision to
deprecate the constructor argument and redirect people to the more
flexible add_argument approach. In the face of ambiguity, refuse the
temptation to guess.
In general, I should say that I'm not opposed to changing the behavior
in Python trunk, even if it causes a bit of backwards incompatibility.
But I'd really like a consensus about the correct behavior, and so far
I have not seen that.
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] Python 2.7b1 and argparse's version action
On Sun, Apr 18, 2010 at 4:03 AM, Nick Coghlan ncogh...@gmail.com wrote: To deal with this in a backwards compatible way while remaining on the path to more conventional behaviour, I suggest the following: 1. For Python 2.7, deprecate *just* the -v default behaviour for the version. This means --version and -v will be set to invoke different actions when the version argument is supplied (the latter will trigger a deprecation warning if supplied, while the former will work normally). It's not clear how you would do this. If you can suggest a patch, I'd be happy to consider it. However, and the moment, you get -v and --version by simply specifying ArgumentParser(..., version=XXX). So how do you deprecate just the -v? All I can imagine you mean is to issue a deprecation warning whenever a user of the script provides -v at the command line, but that seems sketchy to me - we'd be deprecating features of someone's *application*, not features of the argparse *library*. 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] Python 2.7b1 and argparse's version action
On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
Steven Bethard wrote:
By the way, we could simplify the typical add_argument usage by adding
show program's version number and exit as the default help for the
'version' action. Then you should just write:
parser.add_argument('--version', action='version', version='the
version')
With that change, I would have no problem with the current argparse
behaviour (since doing it this way makes it very easy for people to add
a -V shortcut if they want one).
Probably this should happen regardless of the outcome of the
constructor argument. The only reason it wasn't already there is that
I hadn't thought of it. ;-)
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] Python 2.7b1 and argparse's version action
On Sun, Apr 18, 2010 at 3:52 PM, Antoine Pitrou solip...@pitrou.net wrote: Steven Bethard steven.bethard at gmail.com writes: Note that even though I agree with you that -v/--version is probably not the best choice, in the poll[2] 11% of people still wanted this. This strikes me as a small minority. Agreed, but it's also the current behavior, and has been since the beginning of argparse. Note that no one complained about it until Tobias filed the issue in Nov 06, 2009. 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] Python 2.7b1 and argparse's version action
On Sun, Apr 18, 2010 at 4:35 PM, Nick Coghlan ncogh...@gmail.com wrote:
Steven Bethard wrote:
On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
Steven Bethard wrote:
By the way, we could simplify the typical add_argument usage by adding
show program's version number and exit as the default help for the
'version' action. Then you should just write:
parser.add_argument('--version', action='version', version='the
version')
With that change, I would have no problem with the current argparse
behaviour (since doing it this way makes it very easy for people to add
a -V shortcut if they want one).
Probably this should happen regardless of the outcome of the
constructor argument. The only reason it wasn't already there is that
I hadn't thought of it. ;-)
Crazy thought... would it make sense to have the following implicitly
use --version as the option flag:
parser.add_argument(action='version', version='details')
It would be possible, but not simple. The main drawback is that it
would have to be done in the parser code, and not in the VersionAction
class where all the other version behavior is. I think it's not a huge
gain over supplying the option strings, particularly if you're
following, say, the Python executable conventions:
parser.add_argument('-V', action='version', version='details')
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] Python 2.7b1 and argparse's version action
On Sun, Apr 18, 2010 at 6:40 PM, Nick Coghlan ncogh...@gmail.com wrote: Note there are two changes I believe should be made to the argparse documentation for 2.7 though: - the '--version' example should either not use a shorthand, or should use the conventional '-V' - this issue needs to be mentioned in the section on migrating from optparse. Thanks for pointing these out. I'll make a note to fix these when I fix the default help value. 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] Python 2.7b1 and argparse's version action
On Sun, Apr 18, 2010 at 7:02 PM, Ian Bicking i...@colorstudy.com wrote: Somewhat relatedly, what is the plan for past and future argparse releases? I currently don't have any plans to make releases outside of the main Python releases. Perhaps if there's great demand for it, I'll reconsider, but as it is, I haven't had as much time as I would like for argparse, and managing two different types of releases is probably unrealistic for me at the moment. 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.py is licensed under the Apache License
On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc amaur...@gmail.com wrote: I noticed that the newly added argparse module has an unusual licence header, included below. This is the only file in the Python tree that contains an explicit reference to the Apache License, and this leads me to some questions: Sorry, I forgot to remove this when moving argparse to the stdlib. There's probably one test\test_argparse too. - Did the contributor sign a Contributor agreement? In this case, shouldn't the code be marked as Licensed to PSF under a Contributor Agreement, as mentioned in the contribution form? http://www.python.org/psf/contrib/contrib-form And then, could this Apache License be removed? Yes, I have signed a contributor agreement. I was thinking of just removing the license entirely, but if it's better to replace it with Licensed to PSF under a Contributor Agreement, that's fine too. Let me know, and I'll take care of this today. Thanks for catching this! 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 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 Fri, Mar 5, 2010 at 10:51 AM, 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.
If it really bothers you, you can use:
action=argparse._StoreTrueAction
instead. Undocumented (purposefully) but that's all argparse is doing
under the covers.
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] some notes from the first part of the lang summit
Thanks all for the updates. Sorry I can't make it to PyCon this year! On Sun, Feb 21, 2010 at 1:30 AM, Eric Smith e...@trueblade.com wrote: There was also a quick discussion on maybe implementing optparse using argparse, then getting rid of the existing optparse. I think the PEP pretty much already covers why this isn't possible. See: http://www.python.org/dev/peps/pep-0389/#why-isn-t-the-functionality-just-being-added-to-optparse Some of the reasons this would be really difficult include optparse's baroque extension API and the fact that it exposes the internals of its parsing algorithm, which means it's impossible to use a better algorithm that has a different implementation. On Sun, Feb 21, 2010 at 6:19 AM, s...@pobox.com wrote: Would a 2to3 fixer be possible? On Sun, Feb 21, 2010 at 6:29 AM, Benjamin Peterson benja...@python.org wrote: I don't think so. There would be subtle semantic difference 2to3 couldn't detect. Yep, that's probably right. And I don't know how I'd write the fixers for anyone who was using the old optparse extension API. On Sun, Feb 21, 2010 at 5:45 AM, Guido van Rossum gu...@python.org wrote: Maybe the best thing is to make optparse *silently* deprecated, with a big hint at the top of its documentation telling new users to use argparse instead, but otherwise leaving it in indefinitely for the benefit of the many existing users. So basically do what the PEP does now, except don't remove optparse in Python 3.5? For reference, the current proposal is: * Python 2.7+ and 3.2+ -- The following note will be added to the optparse documentation: The optparse module is deprecated and will not be developed further; development will continue with the argparse module. * Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued. * Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. * Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. * Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a DeprecationWarning, which is displayed by default. * Python 3.5 (estimated Jan 2015) -- The optparse module will be removed. So if I drop that last bullet, is the PEP ready for pronouncement? 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] some notes from the first part of the lang summit
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum gu...@python.org wrote: On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard steven.beth...@gmail.com wrote: So basically do what the PEP does now, except don't remove optparse in Python 3.5? For reference, the current proposal is: * Python 2.7+ and 3.2+ -- The following note will be added to the optparse documentation: The optparse module is deprecated and will not be developed further; development will continue with the argparse module. * Python 2.7+ -- If the Python 3 compatibility flag, -3, is provided at the command line, then importing optparse will issue a DeprecationWarning. Otherwise no warnings will be issued. * Python 3.2 (estimated Jun 2010) -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. * Python 3.3 (estimated Jan 2012) -- Importing optparse will issue a PendingDeprecationWarning, which is not displayed by default. * Python 3.4 (estimated Jun 2013) -- Importing optparse will issue a DeprecationWarning, which is displayed by default. * Python 3.5 (estimated Jan 2015) -- The optparse module will be removed. So if I drop that last bullet, is the PEP ready for pronouncement? Drop the last two bullets and it's a deal. (OTOH AFAIK we changed DeprecationWarning so it is *not* displayed by default.) Done: http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse Thank you, and thanks to all who helped in the discussion of this PEP! My plan is to make a final external release of argparse (1.1) fixing some current issues, and then merge that into the Python repository. I should be able to get this done before Python 2.7 alpha 4 on 2010-03-06. 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] some notes from the first part of the lang summit
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon br...@python.org wrote: My notes from the session I led: + argparse - Same issues brought up. For those of us not at PyCon, what were the issues? 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] [RELEASED] Python 2.7 alpha 2
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw ba...@python.org wrote:
As an example, the one library I've already ported used a metaclass. I don't
see any way to specify that the metaclass should be used in a portable way.
In Python 2.6 it's:
class Foo:
__metaclass__ = Meta
and in Python 3 it's:
class Foo(metaclass=Meta):
2to3 made that pain go away.
Actually there's a solution to this one too:
FooBase = Meta('FooBase', (), {})
class Foo(FooBase):
...
That should work in Python 2.X and 3.X.
I've got argparse running on Python 2.3-3.1, and the changes were
pretty easy. You can see them all in the revision here:
http://code.google.com/p/argparse/source/detail?r=12
I have aspirations of putting all of the tricks I learned up up on the
Wiki somewhere, but I just haven't had the time.
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] Pronouncement on PEP 389: argparse?
On Sun, Dec 27, 2009 at 9:51 AM, anatoly techtonik techto...@gmail.com wrote: On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard steven.beth...@gmail.com wrote: If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the Deprecation of optparse section of the PEP: http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse I do not think that optparse should be deprecated at. It is good at what it does and its limitations make its starting point less confusing for people with different backgrounds that Python. Compare: http://docs.python.org/library/optparse.html http://argparse.googlecode.com/svn/tags/r101/doc/index.html This sounds like a request for a documentation change. Because you can write almost identical code with argparse to that in the optparse intro. If you just replace optparse with argparse, OptionParser with ArgumentParser, and (options, args) with args, the code will work exactly the same. (Actually, better because the usage message will be better.) If you have specific suggestions on how you'd like the documentation updated, please file a feature request in the argparse bug tracker: http://code.google.com/p/argparse/issues 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] Pronouncement on PEP 389: argparse?
On Tue, Dec 15, 2009 at 4:33 AM, Neal Becker ndbeck...@gmail.com wrote: Ian Bicking wrote: If argparse doesn't do this, then I think at least it should give good error messages for all cases where these optparse-isms remain. For instance, now if you include %prog in your usage you get: ValueError: unsupported format character 'p' (0x70) at index 1 -- that's simply a bad error message. Giving a proper error message takes about as much code as making %prog work. I don't feel strongly that one is better than the other, but at least one of those should be done. I agree (and I've used both for quite a long time). argparse has an api that is almost compatible with optparse in many common cases, but just renamed some things. I can definitely improve some of the error messages for people coming from optparse. I've created an issue for this, with the ``type='int'`` and %prog problems in there: http://code.google.com/p/argparse/issues/detail?id=51 If you have other things that you know you'd like better exceptions for, please add to that issue and I'll take care of it. 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
[Python-Dev] Pronouncement on PEP 389: argparse?
So there wasn't really any more feedback on the last post of the argparse PEP other than a typo fix and another +1. http://www.python.org/dev/peps/pep-0389/ Can I get a pronouncement? Here's a summary of the responses. (Please correct me if I misinterpreted anyone.) * Floris Bruynooghe +1 * Brett Cannon +1 * Nick Coghlan +1 * Michael Foord +1 * Yuval Greenfield +1 * Doug Hellmann +1 * Kevin Jacobs +1 * Paul Moore +1 * Jesse Noller +1 * Fernando Perez +1 * Jon Ribbens +1 * Vinay Sajip +1 * Barry Warsaw +1 * Antoine Pitrou -0 * Martin v. Löwis -0 * M.-A. Lemburg -1 Note that I've interpreted those who were opposed to the deprecation of getopt as -0 since the PEP no longer proposes that, only the deprecation of optparse. (People who opposed optparse's deprecation are still -1.) If there's any other information that would be helpful for a pronouncement, please let me know. 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking i...@colorstudy.com wrote: On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard steven.beth...@gmail.com wrote: So there wasn't really any more feedback on the last post of the argparse PEP other than a typo fix and another +1. I just converted a script over to argparse. It seems nice enough, I was doing a two-level command, and it was quite handy for that. One concern I had is that the naming seems at times trivially different than optparse, just because opt or option is replaced by arg or argument. So .add_option becomes .add_argument, and OptionParser becomes ArgumentParser. This seems unnecessary to me, and it make converting the application harder than it had to be. It wasn't hard, but it could have been really easy. There are a couple other details like this that I think are worth resolving if argparse really is supposed to replace optparse. Thanks for the feedback. Could you comment further on exactly what would be sufficient? It would be easy, for example, to add a subclass of ArgumentParser called OptionParser that has an add_option method. Do you also need the following things to work? * options, args = parser.parse_args() # options and args aren't separate in argparse * type='int', etc. # string type names aren't used in argparse * action='store_false' default value is None # it's True in argparse These latter kind of changes seem sketchier to me - they would make the initial conversion easier, but would make using argparse normally harder. I'd change this language: The optparse module is deprecated, and has been replaced by the argparse module. To: The optparse module is deprecated and will not be developed further; development will continue with the argparse module Done. Thanks! 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang ole...@gmail.com wrote: On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord On 14/12/2009 19:04, Ian Bicking wrote: Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question I also use -v for verbose in a few scripts (including options to unittest when run with python -m). I've seen -V as a common abbreviation for --version (I've just used this with Mono for example). Many Unix commands accept these switches too . AFAICR there was an standard (well ...) set of command line options for Unix systems (can't find a link :-/ ) Just to be clear, argparse doesn't force you to use -v/--version. That's just the default if you specify the version= argument to the ArgumentParser constructor. You can configure version flags much more flexibly using add_argument(..., action='version'). But yes, it's a poll right now on the argparse website (http://code.google.com/p/argparse/) and if you feel strongly about it, please add your vote there (rather than here). 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang ole...@gmail.com wrote: I thought that one of the following approaches would be considered : - let optparse remain in stdlib (as is or not ...) - re-implement optparse (i.e. a module having the same name ;o) using argparse isn't it ? Please read the PEP if you haven't, particularly the Why isn't the functionality just being added to optparse? section. I don't believe it is sensible to re-implement all of optparse. What Ian Bicking is proposing, I believe, is simpler -- adding a few aliases here and there so that you don't have to rename so many things when you're upgrading from optparse to argparse. For what it's worth, I'm still not sure it's a good idea, for exactly the reason Ian points out - having another class like OptionParser also feels like backward compatibility cruft. 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang ole...@gmail.com wrote: On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang ole...@gmail.com wrote: I thought that one of the following approaches would be considered : 1 - let optparse remain in stdlib (as is or not ...) 2 - re-implement optparse (i.e. a module having the same name ;o) using argparse People also need to remember the very conservative deprecation path for optparse proposed in the PEP - never deprecated in 2.x, So, I don't get it . What's the difference between this and the first option I mentioned above ? I am probably missing the obvious but if optparse will be «never deprecated in 2.x» then what's gonna happen ? The only options I see are mentioned above (and I thought it was the first one ;o) : - If (1) is the right one then -0 for considering backwards compatibility - If (2) is the right one then IMO, +1 for adding «further backwards compatibility cruft» in a separate module and remove it in Python 3.5 If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the Deprecation of optparse section of the PEP: http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse 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] Pronouncement on PEP 389: argparse?
On Mon, Dec 14, 2009 at 4:16 PM, sstein...@gmail.com
sstein...@gmail.com wrote:
On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:
Michael Foord fuzzyman at voidspace.org.uk writes:
I also use -v for verbose in a few scripts (including options to
unittest when run with python -m). I've seen -V as a common abbreviation
for --version (I've just used this with Mono for example).
+1 for letting -v mean --verbose. This is a really common wish.
+1, -v == --verbose
Because people are continuing this discussion, I'll say again that
argparse already supports this:
parser = argparse.ArgumentParser()
parser.add_argument('-v', '--verbose', action='store_true')
parser.parse_args(['-v'])
Namespace(verbose=True)
If you want to also have a -V/--version argument, you can do that too:
parser.add_argument('-V', '--version', action='version', version='3.5')
parser.parse_args(['-V'])
3.5
And now back to our regularly scheduled discussion of actual PEP issues. ;-)
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] 2.7 Release? 2.7 == last of the 2.x line?
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw ba...@python.org wrote: I'd like to read some case studies of people who have migrated applications from 2.6 to 3.0. For what it's worth, it was pretty easy to migrate argparse: http://code.google.com/p/argparse/source/detail?r=12 It was mostly just adding a few aliases, and doing a little sys.exc_info() dance in a couple places because argparse supports Python 2.3 - 3.1 all in the same code base. 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] 2.7 Release? 2.7 == last of the 2.x line?
On Tue, Nov 3, 2009 at 6:14 AM, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: It's pretty easy to make Python source that works under 2.6 and 3.x. It's basically impossible to make Python source that works under 2.4/2.5 and 3.x. This keeps getting quoted later in the thread so I just wanted to say again that this is not true. The argparse module supports Python 2.3-3.1 all from the same codebase, and it really wasn't all that hard: http://code.google.com/p/argparse/source/detail?r=12 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
[Python-Dev] updated PEP 389: argparse
Sorry for the delay, but I've finally updated PEP 389, the argparse
PEP, based on all the feedback from python-dev. The full PEP is below,
but in short, the important changes are:
* The getopt module will *not* be deprecated.
* In Python 2, the -3 flag will cause deprecation warnings to be
issued for optparse.
* No casually visible deprecation warnings for optparse are expected
until Jun 2013.
* Support for {}-format strings will be added when one of the
converters is approved. This can be done at any point though, so it
shouldn't hold up inclusion of argparse.
Steve
--
PEP: 389
Title: argparse - new command line parsing module
Version: $Revision: 75674 $
Last-Modified: $Date: 2009-10-24 12:01:49 -0700 (Sat, 24 Oct 2009) $
Author: Steven Bethard steven.beth...@gmail.com
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 25-Sep-2009
Python-Version: 2.7 and 3.2
Post-History: 27-Sep-2009, 24-Oct-2009
Abstract
This PEP proposes inclusion of the argparse [1]_ module in the Python
standard library in Python 2.7 and 3.2.
Motivation
==
The argparse module is a command line parsing library which provides
more functionality than the existing command line parsing modules in
the standard library, getopt [2]_ and optparse [3]_. It includes
support for positional arguments (not just options), subcommands,
required options, options syntaxes like /f and +rgb, zero-or-more
and one-or-more style arguments, and many other features the other
two lack.
The argparse module is also already a popular third-party replacement
for these modules. It is used in projects like IPython (the Scipy
Python shell) [4]_, is included in Debian testing and unstable [5]_,
and since 2007 has had various requests for its inclusion in the
standard library [6]_ [7]_ [8]_. This popularity suggests it may be
a valuable addition to the Python libraries.
Why aren't getopt and optparse enough?
==
One argument against adding argparse is that thare are already two
different option parsing modules in the standard library [9]_. The
following is a list of features provided by argparse but not present
in getopt or optparse:
* While it is true there are two *option* parsing libraries, there
are no full command line parsing libraries -- both getopt and
optparse support only options and have no support for positional
arguments. The argparse module handles both, and as a result, is
able to generate better help messages, avoiding redundancies like
the ``usage=`` string usually required by optparse.
* The argparse module values practicality over purity. Thus, argparse
allows required options and customization of which characters are
used to identify options, while optparse explicitly states the
phrase 'required option' is self-contradictory and that the option
syntaxes ``-pf``, ``-file``, ``+f``, ``+rgb``, ``/f`` and ``/file``
are not supported by optparse, and they never will be.
* The argparse module allows options to accept a variable number of
arguments using ``nargs='?'``, ``nargs='*'`` or ``nargs='+'``. The
optparse module provides an untested recipe for some part of this
functionality [10]_ but admits that things get hairy when you want
an option to take a variable number of arguments.
* The argparse module supports subcommands, where a main command
line parser dispatches to other command line parsers depending on
the command line arguments. This is a common pattern in command
line interfaces, e.g. ``svn co`` and ``svn up``.
Why isn't the functionality just being added to optparse?
=
Clearly all the above features offer improvements over what is
available through optparse. A reasonable question then is why these
features are not simply provided as patches to optparse, instead of
introducing an entirely new module. In fact, the original development
of argparse intended to do just that, but because of various fairly
constraining design decisions of optparse, this wasn't really
possible. Some of the problems included:
* The optparse module exposes the internals of its parsing algorithm.
In particular, ``parser.largs`` and ``parser.rargs`` are guaranteed
to be available to callbacks [11]_. This makes it extremely
difficult to improve the parsing algorithm as was necessary in
argparse for proper handling of positional arguments and variable
length arguments. For example, ``nargs='+'`` in argparse is matched
using regular expressions and thus has no notion of things like
``parser.largs``.
* The optparse extension APIs are extremely complex. For example,
just to use a simple custom string-to-object conversion function,
you have to subclass ``Option``, hack class attributes, and then
specify your custom option type to the parser, like this::
class MyOption(Option):
TYPES = Option.TYPES
Re: [Python-Dev] updated PEP 389: argparse
On Sat, Oct 24, 2009 at 4:34 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Steven Bethard steven.beth...@gmail.com writes: Discussion: sys.err and sys.exit There were some concerns that argparse by default always writes to ``sys.err`` […] Unless, I'm missing something, this should replace ‘sys.err’ with ‘sys.stderr’ throughout. Yep, that's a typo. Thanks for the catch. It's fixed in SVN and the website: http://www.python.org/dev/peps/pep-0389/ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Tue, Oct 20, 2009 at 7:44 PM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 21, 2009 at 5:49 AM, Paul Moore p.f.mo...@gmail.com wrote: 2009/10/20 Chris Withers ch...@simplistix.co.uk: There are many (I believe) Windows users for whom bdist_wininst is just what they want. For those people, where's the incentive to switch in what you propose? You're not providing the features they currently have, and frankly do the work yourself is no answer (not everyone can, often for entirely legitimate reasons). I am not so familiar with msi or wininst internals, but isn't it possible to install w.r.t. a given prefix ? This is definitely supported by the msi. In fact, you can do this at the command line (although I don't know if this is considered officially supported or not): $ argparse-1.0.2.win32-py2.6.msi /quiet TARGETDIR=C:\TempPython $ dir C:\TempPython\Lib\site-packages Volume in drive C has no label. Volume Serial Number is B6E6-4B4D Directory of C:\TempPython\Lib\site-packages 10/20/2009 10:04 PMDIR . 10/20/2009 10:04 PMDIR .. 10/20/2009 10:03 PM 1,584 argparse-1.0.2-py3.1.egg-info 10/09/2009 11:03 AM86,620 argparse.py 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Sun, Oct 11, 2009 at 9:52 AM, Paul Moore p.f.mo...@gmail.com wrote: 2009/10/9 Michael Foord fuzzy...@voidspace.org.uk: Many Windows users would be quite happy if the standard mechanism for installing non-source distributions on Windows was via the wininst binaries. +1 I'm one of those people. +1 on installing packages on Windows through the native package manager (Add/Remove Programs). I am working with Tarek to keep Windows issues (and in particular this one) on the agenda. It's quite hard at times, as getting a representative sample of Windows users' preferences/requirements is difficult at best (Windows users seem as a group to be either very quiet, or very easy to please. I'm an exception :-)) If any Windows users want to speak up and help, that would be immensely useful! (And please, identify yourself as such - it's often hard to determine who knows Windows, and who is a Unix user making assumptions or best guesses). I'm a Windows user, and I've also spent a fair bit of time improving Python's bdist_msi support exactly so that we have better support for Windows native package management. However, I don't have enough time to keep up with the massive package management threads. If you want to CC me occasionally to get my feedback on a particular comment though, I'd be happy to speak up. 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] PEP 389: argparse - new command line parsing module
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle ubershme...@gmail.com wrote: I haven't checked if it's possible, but I suggest Argparse have it's own exception class that inherits from SystemExit and that exception would be thrown. ParseError, or something similar. I suggest this just because it would be more readable I guess and would exactly explain why this code exits. I've never seen such an idiom before (subclassing SystemExit) but it would certainly be possible create an ArgumentParserExit exception like that. Then you would have your choice of overriding .exit() or catching the exception. 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
[Python-Dev] summary of transitioning from % to {} formatting
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
The basic problem is that many APIs in the standard library and
elsewhere support only %-formatting and not {}-formatting, e.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
There seems to be mostly agreement that these APIs should at least
support both formatting styles, and a sizable group (including Guido)
believe that %-formatting should eventually be phased out (e.g. by
Python 4). There are a number of competing proposals on how to allow
such APIs to start accepting {}-format strings:
* Add a parameter which declares the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
* Create string subclasses which convert % use to .format calls::
__ = brace_fmt
logging.Formatter(fmt=__({asctime} - {name}))
The API code wouldn't have to change at all at first, as applying
% to brace_fmt objects would call .format() instead. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring brace_fmt strings, and
then allowing plain strings again but assuming they are {}-format
strings.
* Teach the API to accept callables as well as strings::
logging.Formatter(fmt={asctime} - {name}.format)
The API code would just call the object with .format() style
arguments if a callable was given instead of a string. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring callables, and then
allowing plain strings again but assuming they are {}-format
strings
* Create translators between %-format and {}-format::
assert to_braces(%(asctime)s) == {asctime}
assert to_percents({asctime}) == %(asctime)s
these could then either be used outside of the API::
logging.Formatter(fmt=to_percents({asctime} - {name}))
or they could be used within the API combined with some sort of
heuristic for guessing whether a {}-format string or a %-format
string was passed in::
logging.Formatter(fmt={asctime} - {name})
If %-formatting is to be deprecated, the transition strategy here
is trivial. However, no one has yet written translators, and it is
not clear what heuristics should be used, e.g. should the method
just try %-formatting first and then {}-formatting if it fails?
I don't think there is consensus yet on which of these proposals
should be the blessed one.
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] PEP 389: argparse - new command line parsing module
On Sat, Oct 3, 2009 at 8:17 AM, Michael Foord fuzzy...@voidspace.org.uk wrote:
Steven Bethard wrote:
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle ubershme...@gmail.com
wrote:
I haven't checked if it's possible, but I suggest Argparse have it's
own exception class that inherits from SystemExit and that exception
would be thrown.
I've never seen such an idiom before (subclassing SystemExit) but it
would certainly be possible create an ArgumentParserExit exception
like that. Then you would have your choice of overriding .exit() or
catching the exception.
Why not just catch SystemExit? If you want a custom exception the overriding
.exit() should be sufficient.
I'm certainly fine with that -- I'm just trying to make sure I've
addressed whatever needs addressed to get argparse in.
I'd be much more interested in Guido's suggestion of auto-generated custom
help messages for sub-commands.
Maybe I misunderstood, but I think this is already the default
argparse behavior, no?
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers()
parser1 = subparsers.add_parser('1')
parser1.add_argument('--bar')
parser2 = subparsers.add_parser('2')
parser2.add_argument('baz')
parser.parse_args(['--help'])
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers()
parser1 = subparsers.add_parser('1')
parser1.add_argument('--bar')
parser2 = subparsers.add_parser('2')
parser2.add_argument('baz')
# top level argument help
parser.parse_args(['--help'])
usage: [-h] [--foo FOO] {1,2} ...
positional arguments:
{1,2}
optional arguments:
-h, --help show this help message and exit
--foo FOO
# help for subparser 1
parser.parse_args(['1', '--help'])
usage: 1 [-h] [--bar BAR]
optional arguments:
-h, --help show this help message and exit
--bar BAR
# help for subparser 2
parser.parse_args(['2', '--help'])
usage: 2 [-h] baz
positional arguments:
baz
optional arguments:
-h, --help show this help message and exit
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] transitioning from % to {} formatting
On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy tjre...@udel.edu wrote:
As someone who likes .format() and who already uses such bound methods to
print, such as in
emsg = format
...
if c: print(emsg(arg, barg))
I find this **MUCH** preferable to the ugly and seemingly unnecessary
wrapper class idea being bandied about. This would be scarcely worse than
passing the string itself.
But it's not much of a transition plan. Or are you suggesting:
(1) Make API accept callables
(2) Issue warnings for regular strings
(3) Throw exceptions for regular strings
(4) Allow regular strings again, but assume {}-style formatting
?
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] transitioning from % to {} formatting
On Fri, Oct 2, 2009 at 2:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
Steven Bethard steven.bethard at gmail.com writes:
But it's not much of a transition plan. Or are you suggesting:
The question is why we want a transition plan that will bother everyone with
no
tangible benefits for the user.
I think Guido expressed my feelings pretty well:
On Wed, Sep 30, 2009 at 10:37 AM, Guido van Rossum gu...@python.org wrote:
In the long run, say Python 4, I think we don't need both, and we
should get rid of one. My preference is still getting rid of
%-formatting, due to the problems with it that prompted the design of
{}-formatting (no need to reiterate the list here).
I agree with this 100% but I can't see it working unless we have some
sort of transition plan. Just saying ok, switch your format strings
from % to {} didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.
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] transitioning from % to {} formatting
On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler m...@lazybytes.net wrote:
I hate calling methods on string literals, I think it looks very odd to
have code like this:
Displaying {0} of {1} revisions.format(x, y)
Will we be able to write this as
Displaying {0} of {1} revisions % (x, y)
too?
I doubt it. One of the major complaints about the %-style formatting
was that the use of % produced (somewhat) unexpected errors because of
how operator precedence works::
'{0}'.format(4 + 1)
'5'
'%s' % 4 + 1
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: cannot concatenate 'str' and 'int' objects
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] transitioning from % to {} formatting
On Fri, Oct 2, 2009 at 11:56 AM, Raymond Hettinger pyt...@rcn.com wrote:
[Steven Bethard]
Just saying ok, switch your format strings
from % to {} didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.
Do the users get any say in this?
I imagine that some people are heavily invested in %-formatting.
Because there has been limited uptake on {}-formatting (afaict),
we still have limited experience with knowing that it is actually
better, less error-prone, easier to learn/rember, etc. Outside
a handful of people on this list, I have yet to see anyone adopt
it as the preferred syntax.
Sure, I guess this is a possibility too, and it could make the
transition process I have to work through for argparse much easier.
;-)
To be clear, are you suggesting that APIs that currently support only
%-formatting shouldn't bother supporting {}-formatting at all? Or are
you suggesting that they should support both, but support for
%-formatting should never go away?
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] transitioning from % to {} formatting
On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon br...@python.org wrote:
So I created this last night:
import collections
class braces_fmt(str):
def __mod__(self, stuff):
if isinstance(stuff, tuple):
return self.__class__(self.format(*stuff))
elif isinstance(stuff, collections.Mapping):
return self.__class__(self.format(**stuff))
else:
return self.__class__(self.format(stuff))
The biggest issue is that ``%s % {'a': 42}`` substitutes the dict
instead of throwing an error that str.format() would do with the code
above. But what's nice about this is I think I can use this now w/ any
library that expects % interpolation and it should basically work.
I see how this could allow a user to supply a {}-format string to an
API that accepts only %-format strings. But I still don't see the
transition strategy for the API itself. That is, how does the %-format
API use this to eventually switch to {}-format strings? Could someone
please lay it out for me, step by step, showing what happens in each
version?
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] transitioning from % to {} formatting
On Thu, Oct 1, 2009 at 4:35 PM, Brett Cannon br...@python.org wrote:
On Thu, Oct 1, 2009 at 15:19, Steven Bethard steven.beth...@gmail.com wrote:
On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon br...@python.org wrote:
class braces_fmt(str):
def __mod__(self, stuff):
if isinstance(stuff, tuple):
return self.__class__(self.format(*stuff))
elif isinstance(stuff, collections.Mapping):
return self.__class__(self.format(**stuff))
else:
return self.__class__(self.format(stuff))
The biggest issue is that ``%s % {'a': 42}`` substitutes the dict
instead of throwing an error that str.format() would do with the code
above. But what's nice about this is I think I can use this now w/ any
library that expects % interpolation and it should basically work.
Could someone please lay it out for me, step by step, showing what
happens in each version?
1. Nothing changes as hopefully the wrapper works fine (as people are
pointing out, though, my approach needs to override __str__() to
return 'self', else the str type will just return what it has
internally in its buffer).
2. Raise a deprecation warning when ``isinstance(ob, brace_fmt)`` is
false. When a class is passed in that is a subclass of brace_fmt, call
ob.format() on it.
3. Require the subclass.
4. Remove the requirement and always call ob.format().
Thanks Brett, that's clear. So you save one version over the proposal
of adding a format= flag to the API.
On Thu, Oct 1, 2009 at 4:13 PM, James Y Knight f...@fuhm.net wrote:
Here's what I said in my first message, suggesting this change. Copypasted
below:
[snip steps that only talk about str.__mod__, not an API that uses it]
I didn't understand how you wanted to apply your suggestion to an API
(instead of str.__mod__) the first time and I still don't understand
it. Is what Brett has proposed the same thing?
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] transitioning from % to {} formatting
On Tue, Sep 29, 2009 at 10:04 PM, James Y Knight f...@fuhm.net wrote:
It'd possibly be helpful if there were builtin objects which forced the
format style to be either newstyle or oldstyle, independent of whether % or
format was called on it.
E.g.
x = newstyle_formatstr({} {} {})
x % (1,2,3) == x.format(1,2,3) == 1 2 3
and perhaps, for symmetry:
y = oldstyle_formatstr(%s %s %s)
y.format(1,2,3) == x % (1,2,3) == 1 2 3
This allows the format string style decision is to be made external to the
API actually calling the formatting function. Thus, it need not matter as
much whether the logging API uses % or .format() internally -- that only
affects the *default* behavior when a bare string is passed in.
This could allow for a controlled switch towards the new format string
format, with a long deprecation period for users to migrate:
1) introduce the above feature, and recommend in docs that people only ever
use new-style format strings, wrapping the string in newstyle_formatstr()
when necessary for passing to an API which uses % internally.
2) A long time later...deprecate str.__mod__; don't deprecate
newstyle_formatstr.__mod__.
3) A while after that (maybe), remove str.__mod__ and replace all calls in
Python to % (used as a formatting operator) with .format() so that the
default is to use newstyle format strings for all APIs from then on.
So I understand how this might help a user to move from %-style
formatting to {}-style formatting, but it's still not clear to me how
to use this to evolve an API. In particular, if the goal is for the
API to move from accepting %-style format strings to {}-style format
strings, how should that API use newstyle_formatstr or
oldstyle_formatstr to make this transition?
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] transitioning from % to {} formatting
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw ba...@python.org wrote:
On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I would call the argument format (like the method name of the
string type), i.e.
logging.Formatter(
format={asctime} - {name} - {levelname} - {message})
For the % formatting, I suggest dicttemplate (assuming that
you *have* to use dictionary %(key)s style currently).
The positional parameter would also mean dicttemplate, and
would be deprecated (eventually requiring a keyword-only
parameter).
Although I hate the name 'dicttemplate', this seems like the best solution
to me. Maybe it's good that 'dicttemplate' is so ugly though so that people
will naturally prefer 'format' :). But I like this because there's not
really any magic, it's explicit, and the decision is made by the coder at
the call site. The implementation does not need to guess at all.
Could you comment on what you think we should do when the parameter is
not positional? As I mentioned upthread, in the case of
logging.Formatter, it's already documented as taking the keyword
parameter fmt, so we'd have to use the name fmt for % formatting.
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] transitioning from % to {} formatting
On Wed, Sep 30, 2009 at 8:31 AM, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw ba...@python.org wrote:
On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I would call the argument format (like the method name of the
string type), i.e.
logging.Formatter(
format={asctime} - {name} - {levelname} - {message})
For the % formatting, I suggest dicttemplate (assuming that
you *have* to use dictionary %(key)s style currently).
Could you comment on what you think we should do when the parameter is
not positional? As I mentioned upthread, in the case of
logging.Formatter, it's already documented as taking the keyword
parameter fmt, so we'd have to use the name fmt for % formatting.
I'm okay with fmt==%-formatting and format=={}-formatting, but I'd also be
okay with transitioning 'fmt' to 'dicttemplate' or whatever. I think the
important thing is to be explicit in the method signature which one you want
(secondary would be trying to standardize this across the stdlib).
Thanks for the clarification. I generally like this approach, though
it's not so convenient for argparse which already takes format strings
like this::
parser = ArgumentParser(usage='%(prog)s [--foo]')
parser.add_argument(
'--foo', type=int, default=42,
help='A foo of type %(type)s, defaulting to %(42)s)
That is, existing keyword arguments that already have good names (and
are pretty much always used as keyword arguments) take format strings.
I'm not sure that changing the name of usage= or help= here is really
an option.
I guess in this case I'm stuck with something like Benjamin's
suggestion of adding an additional flag to control which type of
formatting, and the corresponding 4 versions of cleanup. Ew.
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] transitioning from % to {} formatting
On Wed, Sep 30, 2009 at 8:50 AM, Barry Warsaw ba...@python.org wrote:
On Sep 30, 2009, at 11:39 AM, Steven Bethard wrote:
Thanks for the clarification. I generally like this approach, though
it's not so convenient for argparse which already takes format strings
like this::
parser = ArgumentParser(usage='%(prog)s [--foo]')
parser.add_argument(
'--foo', type=int, default=42,
help='A foo of type %(type)s, defaulting to %(42)s)
Yep, sorry, typo, that should have been %(default)s, not %(42)s.
I guess in this case I'm stuck with something like Benjamin's
suggestion of adding an additional flag to control which type of
formatting, and the corresponding 4 versions of cleanup. Ew.
I missed Benjamin's suggestion, but in this case I would say add a flag to
ArgumentParser. I'm either going to want {} formatting all or nothing.
E.g.
import argparse
parser = ArgumentParser(usage='{prog} [--foo]', format=argparse.BRACES)
Yeah, that's basically Benjamin's suggestion, with the transition path being:
(1) Introduce format= keyword argument, defaulting to PERCENTS
(2) Deprecate format=PERCENTS
(3) Error on format=PERCENTS (Benjamin suggested just changing the
default here, but that would give a release where errors would pass
silently)
(4) Deprecate format= keyword argument.
(5) Remove format= keyword argument.
It's a little sad that it takes 5 versions to do this, but I guess if
a user is on top of things, at version (1) they add format=BRACES to
all their code, and then remove those at version (4). So even though
there are 5 versions, there are only two code changes required.
At least in the case of argparse, this can be a constructor argument
as you suggest, and we only have to introduce this flag in one place.
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] PEP 389: argparse - new command line parsing module
On Wed, Sep 30, 2009 at 1:17 PM, Andrew McNabb amcn...@mcnabbs.org wrote: From my cursory reading of the documentation, it looks like argparse can only add subparsers for subcommands. Is there any way to add subparsers based on options instead (as iptables does)? Currently this is not supported, but it would be a nice feature. Also, is it possible to add these subparsers dynamically? For example, you would want to be able to load a module immediately after parsing the name instead of having to keep a predetermined list of all module names. I'm pretty sure that bzr dynamically loads modules this way. Can argparse help with this? You can probably already do this. I'm not 100% sure what you want to do, but it's certainly possible to define an argparse.Action that loads a module when it's invoked. It might look something like:: class MyAction(argparse.Action): def __call__(self, parser, namespace, value, option_string=None): mod = __import__(value) # or whatever 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] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore p.f.mo...@gmail.com wrote: 2009/9/28 Yuvgoog Greenle ubershme...@gmail.com: 1. There is no chance of the script killing itself. In argparse and optparse exit() is called on every parsing error (btw because of this it sucks to debug parse_args in an interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). This is behavior that argparse inherits from optparse, but I believe it's still what 99.9% of users want. If you're writing a command line interface, you don't want a stack trace when there's an error message (which is what you'd get if argparse just raised exceptions) you want an exit with an error code. That's what command line applications are supposed to do. If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. 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] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On approximately 9/29/2009 1:57 PM, came the following characters from the keyboard of Steven Bethard: If you're not using argparse to write command line applications, then I don't feel bad if you have to do a tiny bit of extra work to take care of that use case. In this particular situation, all you have to do is subclass ArgumentParser and override exit() to do whatever you think it should do. [snip] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. I'm totally fine with people thinking it is only useful for console applications. That's what it's intended for. That said, if there are people out there who want to use it for other applications, I'm happy to make things easier for them if I know concretely what they want. An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. I don't really use GUI libraries, so I wouldn't be able to come up with such an example. I'd also rather not make API changes based on speculative use cases, so before I spend time documenting these things, I'd really like to hear from someone who has already, say, used getopt or optparse in conjunction with a GUI library, and what feedback they have about that. 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
[Python-Dev] transitioning from % to {} formatting
There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting. We should really provide
some sort of transition plan. Consider an example from the logging
docs:
logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s)
We'd like to support both this style as well as the following style:
logging.Formatter({asctime} - {name} - {levelname} - {message})
Perhaps we'd eventually deprecate the %-style formatting, but at least
in the intervening time, we'd have to support both. I see a few
possibilities:
* Add a new class, NewFormatter, which uses the {}-style formatting.
This is ugly because it makes the formatting we're trying to encourage
look like the alternative implementation instead of the standard one.
It also means we have to come up with new names for every API that
uses format strings.
* Have Formatter try to guess whether it got %-style formatting or
{}-style formatting, and then delegate to the appropriate one. I don't
know how accurately we can guess. We also end up still relying on both
formatting styles under the hood.
* Have Formatter convert all %-style formatting strings to {}-style
formatting strings (automatically). This still involves some guessing,
and involves some serious hacking to translate from one to the other
(maybe it wouldn't even always be possible?). But at least we'd only
be using {}-style formatting under the hood.
Thoughts?
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] transitioning from % to {} formatting
On Tue, Sep 29, 2009 at 5:54 PM, Benjamin Peterson benja...@python.org wrote:
* Provide a flag to Formatter which controls whether new or old
formatting is used. Emit a warning when it's not true.
So then the transition strategy is something like:
version N: Add formatting flag which uses {}-style formatting on True
and %-style formatting on False, which defaults to False
version N + 1: Deprecate False value for formatting flag (all code
should start specifying flag=True)
version N + 2: Raise error on False value for formatting flag (all
code must specify flag=True)
version N + 3: Deprecate formatting flag
version N + 4: Remove formatting flag
?
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] PEP 389: argparse - new command line parsing module
On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan ncogh...@gmail.com wrote: Keeping getopt around *and* including a add_getopt_arguments method in argparse is probably the best of both worlds, in that it allows for relatively straightforward evolution of an application: 1. Start with getopt 2. As the getopt argument parsing gets twisty and arcane and maintaining the help string becomes a nightmare, move to argparse with the add_getopt_arguments method. 3. Over time, convert more arguments to proper argparse arguments with full documentation. One thing that wouldn't be good in this transition is that add_getopt_arguments can only generate the part of the help string that says -a and --author exist as options -- it can't add the additional bit of text that says what they do because that's not provided to the getopt API. I suspect this makes the transition less convenient because with getopt you were probably already manually maintaining a usage message that had at least some of this information, and switching to add_getopt_arguments would mean throwing this information away. 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] transitioning from % to {} formatting
On Tue, Sep 29, 2009 at 8:15 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Steven Bethard wrote:
Consider an example from the logging
docs:
logging.Formatter(%(asctime)s - %(name)s - %(levelname)s - %(message)s)
We'd like to support both this style as well as the following style:
logging.Formatter()
Now, that's different. IIUC, you are not actually performing the
substitution here, but only at a later place.
So changing to the new formatting mechanism is an API change.
I agree that the new placeholder syntax needs to be supported.
Just to be clear, I don't think logging is the only place these kind
of things happen. Some others I found looking around:
BaseHTTPServer.BaseHTTPRequestHandler.error_message_format
http://docs.python.org/library/basehttpserver.html#BaseHTTPServer.BaseHTTPRequestHandler.error_message_format
BaseHTTPServer.BaseHTTPRequestHandler.log_message
http://docs.python.org/3.1/library/http.server.html#http.server.BaseHTTPRequestHandler.log_message
email.generator.DecodedGenerator
http://docs.python.org/library/email.generator.html#email.generator.DecodedGenerator
There may be more.
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I would call the argument format (like the method name of the
string type), i.e.
logging.Formatter(
format={asctime} - {name} - {levelname} - {message})
For the % formatting, I suggest dicttemplate (assuming that
you *have* to use dictionary %(key)s style currently).
The positional parameter would also mean dicttemplate, and
would be deprecated (eventually requiring a keyword-only
parameter).
This is a nice solution for the cases where we can be confident that
the parameter is currently only used positionally. However, at least
in Python 3.1, fmt is already documented as a keyword parameter:
http://docs.python.org/3.1/library/logging.html#logging.Formatter
I guess we could follow the same approach though, and have fmt= be the
%-style formatting, and use some other keyword argument for {}-style
formatting.
We've got a similar problem for the
BaseHTTPRequestHandler.error_message_format attribute. I guess we'd
want to introduce some other attribute which is the error message
format for the {}-style formatting?
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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. But that doesn't tell me why we should deprecate optparse, when it may work perfectly well for some people. Because it's basically unmaintained, and anything you can do in optparse you can do in argparse with almost identical syntax. So encouraging people to move from getopt and optparse to argparse is a net gain for us as Python maintainers -- that's two fewer modules in the standard library that someone has to take care of bug reports for. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens jon+python-...@unequivocal.co.uk wrote: On Mon, Sep 28, 2009 at 09:38:20AM +0100, Floris Bruynooghe wrote: On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote: -1 for deprecating getopt. getopt is super-simple and especially useful for c programmers learning python. +1 for argparse.+1 for eventual deprecation of optparse - optparse and argparse have a very similar syntax and having both is just confusing. tsboapooowtdi +1 on all of this :-) It would be a shame to see getopt go but optparse - argparse seems logical. +1 from me too - keep getopt, deprecate optparse. Ok, sounds like there are a number of supporters for keeping getopt around and just deprecating optparse. For those who'd like to keep getopt around, I have a few questions: * Would you be opposed to a note in the getopt documentation suggesting argparse as an alternative? * Would you like argparse to grow an add_getopt_arguments method (as in my other post)? * If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why? 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 4:09 AM, Neal Becker ndbeck...@gmail.com wrote: If the plan is to migrate from optparse to argparse, this could be made a bit easier. If it weren't for the fact that some names are different in argparse than optparse, I believe many optparse usages could port with no change. I could conceivably add an OptionParser class which:: * Has an add_option method which delegates to add_argument * Has a parse_args method which delegates to parse_known_args * Registers the string names for types that optparse uses That might allow some users to just switch their import as long as they're not using any callbacks, catching any exceptions, extending any APIs, etc. I'm not 100% convinced that it's good to add a subtly different API that people would have to unlearn, but if there's enough support for this, I'm open to the idea. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: m h wrote: Perhaps this is OT, but since command line parsing is part of configuration, I figure I'd throw it out there. My scripts often have configuration that the command line can override and I loosely follow the example hierarchy[0] listed in The Art of Unix Programming. Some configuration I want in a config file (but I want to override from the command line) and sometimes it's very nice to use environment variables for configuration. So I do something like this: Integration with command line options is an occasionally-requested feature for ConfigObj. I've always said I would be open to patches... In other words, yes I think there is demand for it. Whether it belongs *immediately* in the standard library is another matter, but if you wrote a layer that unified ConfigParser and argparse I think you will find that people use it. It is well outside the realm of this PEP however. What Michael said. ;-) If you'd like to provide a patch for argparse that provides such functionality, I'd be happy to review it. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info wrote: On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote: * Would you like argparse to grow an add_getopt_arguments method (as in my other post)? 0 * If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why? Simplicity of the learning curve. Using it is as simple as: getopt.getopt(sys.argv[1:], a:b, [alpha=, beta]) You forgot the for-loop, nested if/else statements and type conversions. ;-) Does argparse allow anything as simple as that? If you mean, does argparse allow configuration to be specified using the getopt style (a:b, [alpha=, beta]), no, it currently doesn't. But if this is useful functionality, and would reasonably replace the getopt use cases, then I'd be happy to add it. In the simplest version, we might add something like:: options, args = argparse.getopt(a:b, [alpha=, beta]) where you could then use options without any looping:: alpha = options.a or options.alpha beta = options.b or options.beta But if people still like the traditional getopt loop with nested if/elses better, then we might as well just keep getopt around and not add anything to argparse. I'm fine with that too, I just want to make sure that there isn't an obvious deficiency in argparse that we could easily fix. 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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon br...@python.org wrote:
On Mon, Sep 28, 2009 at 08:49, Steven Bethard steven.beth...@gmail.com
wrote:
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano st...@pearwood.info wrote:
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you like argparse to grow an add_getopt_arguments method (as
in my other post)?
0
* If argparse grew an add_getopt_arguments, would you still want to
keep getopt around? And if so, why?
Simplicity of the learning curve. Using it is as simple as:
getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
You forgot the for-loop, nested if/else statements and type conversions. ;-)
=) I do wonder if people who are advocating for getopt sticking around
realize how much extra code must be written to make sure what it gives
back to you is in some sane manner.
Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])``
as an example and simply assume that 'alpha' takes a string as an
argument and that it's required and that 'beta' is a boolean flag. To
pull everything out you could do::
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
options_dict = dict(options)
alpha = options_dict.get('-a', options_dict.get('--alpha', ''))
beta = '-b' in options_dict or '--beta' in options_dict
main(alpha, beta, args)
Obviously if one of the getopt supporters has a better way of doing
this then please speak up.
Now, Steven, can you show how best to do this in argparse?
Here's the same option parsing in argparse:
parser = argparse.ArgumentParser()
parser.add_argument('-a', '--alpha')
parser.add_argument('-b', '--beta', action='store_true')
args = parser.parse_args()
main(args.alpha, args.beta)
Or if those final positional arguments were actually meaningful, then
you would add one more argument like this::
parser = argparse.ArgumentParser()
parser.add_argument('-a', '--alpha')
parser.add_argument('-b', '--beta', action='store_true')
parser.add_argument('gammas', nargs='*')
args = parser.parse_args()
main(args.alpha, args.beta, args.gammas)
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] PEP 389: argparse - new command line parsing module
On Mon, Sep 28, 2009 at 8:44 PM, Martin v. Löwis mar...@v.loewis.de wrote: Let's take ``getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])`` As Yuvgoog Greenle says, the canonical getopt way is to write [snip getopt code] Even though this is many more lines, I prefer it over optparse/argparse: this code has only a single function call, whereas the argparse version has three function calls to remember. The actual processing uses standard Python data structures which I don't need to look up in the documentation. Now, Steven, can you show how best to do this in argparse? This demonstrates my point: you were able to use getopt right away (even though not in the traditional way), whereas you need to ask for help on using argparse properly. I don't think this is fair at all. I am totally unable to write getopt code without checking the documentation -- I don't remember the format string syntax, nor what the function returns. But that's just how library modules work -- if you don't know the library, you have to read the documentation. The only reason getopt is easier for you is that you're already familiar with the API from C. That said, I can certainly understand that folks who use getopt in C would have an easy transition to getopt in Python and a harder transition to argparse. You didn't directly answer my question of whether adding an add_getopt_arguments function would meet your needs, but I infer from your answer above that it wouldn't because you'd still need to make multiple function calls which is your primary complaint. So at this point, I think it's clear that there's nothing I can reasonably add to argparse to make getopt people more comfortable that isn't just duplicating what's already in getopt. So let's just deprecate optparse (as in the PEP), and leave getopt alone (other than adding a note to the documentation suggesting argparse as an alternative). -- 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
[Python-Dev] PEP 389: argparse - new command line parsing module
Below is a new PEP based on discussions from the stdlib-sig, which proposes to add the argparse module to the standard library in Python 2.7 and 3.2. Looking forward to your feedback! Steve http://www.python.org/dev/peps/pep-0389/ -- PEP: 389 Title: argparse - new command line parsing module Version: $Revision: 75097 $ Last-Modified: $Date: 2009-09-27 12:42:40 -0700 (Sun, 27 Sep 2009) $ Author: Steven Bethard steven.beth...@gmail.com Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 25-Sep-2009 Python-Version: 2.7 and 3.2 Post-History: Abstract This PEP proposes inclusion of the argparse [1]_ module in the Python standard library in Python 2.7 and 3.2. Motivation == The argparse module is a command line parsing library which provides more functionality than the existing command line parsing modules in the standard library, getopt [2]_ and optparse [3]_. It includes support for positional arguments (not just options), subcommands, required options, options syntaxes like /f and +rgb, zero-or-more and one-or-more style arguments, and many other features the other two lack. The argparse module is also already a popular third-party replacement for these modules. It is used in projects like IPython (the Scipy Python shell) [4]_, is included in Debian testing and unstable [5]_, and since 2007 has had various requests for its inclusion in the standard library [6]_ [7]_ [8]_. This popularity suggests it may be a valuable addition to the Python libraries. Why aren't getopt and optparse enough? == One argument against adding argparse is that thare are already two different option parsing modules in the standard library [9]_. The following is a list of features provided by argparse but not present in getopt or optparse: * While it is true there are two *option* parsing libraries, there are no full command line parsing libraries -- both getopt and optparse support only options and have no support for positional arguments. The argparse module handles both, and as a result, is able to generate better help messages, avoiding redundancies like the ``usage=`` string usually required by optparse. * The argparse module values practicality over purity. Thus, argparse allows required options and customization of which characters are used to identify options, while optparse explicitly states the phrase 'required option' is self-contradictory and that the option syntaxes ``-pf``, ``-file``, ``+f``, ``+rgb``, ``/f`` and ``/file`` are not supported by optparse, and they never will be. * The argparse module allows options to accept a variable number of arguments using ``nargs='?'``, ``nargs='*'`` or ``nargs='+'``. The optparse module provides an untested recipe for some part of this functionality [10]_ but admits that things get hairy when you want an option to take a variable number of arguments. * The argparse module supports subcommands, where a main command line parser dispatches to other command line parsers depending on the command line arguments. This is a common pattern in command line interfaces, e.g. ``svn co`` and ``svn up``. Why isn't the functionality just being added to optparse? = Clearly all the above features offer improvements over what is available through optparse. A reasonable question then is why these features are not simply provided as patches to optparse, instead of introducing an entirely new module. In fact, the original development of argparse intended to do just that, but because of various fairly constraining design decisions of optparse, this wasn't really possible. Some of the problems included: * The optparse module exposes the internals of its parsing algorithm. In particular, ``parser.largs`` and ``parser.rargs`` are guaranteed to be available to callbacks [11]_. This makes it extremely difficult to improve the parsing algorithm as was necessary in argparse for proper handling of positional arguments and variable length arguments. For example, ``nargs='+'`` in argparse is matched using regular expressions and thus has no notion of things like ``parser.largs``. * The optparse extension APIs are extremely complex. For example, just to use a simple custom string-to-object conversion function, you have to subclass ``Option``, hack class attributes, and then specify your custom option type to the parser, like this:: class MyOption(Option): TYPES = Option.TYPES + (mytype,) TYPE_CHECKER = copy(Option.TYPE_CHECKER) TYPE_CHECKER[mytype] = check_mytype parser = optparse.OptionParser(option_class=MyOption) parser.add_option(-m, type=mytype) For comparison, argparse simply allows conversion functions to be used as ``type=`` arguments directly, e.g.:: parser = argparse.ArgumentParser
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou solip...@pitrou.net wrote: I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. Could you elaborate? If you are worried about Python 2.X scripts, note from the PEP that the only things that will ever show up in Python 2.X are: PendingDeprecation warnings, which by default are not displayed, and documentation notes directing users of getopt and optparse to argparse. I think these messages are useful for folks using 2.X who some day would like to migrate to 3.X, and at the same time should have zero effect on existing scripts. If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? Transitioning to Python 3 is already a pain. bytes/str/unicode things are going to be enough by themselves to drive people nuts. We don't want to be forcing them to change APIs if optparse is already working just fine for them. The job is the stdlib is not to force people to use the best or right tools. Several years in the future I would be more supportive of depreacting optparse, but more ways in which 2.x and 3.x grow farther apart are not going to help jumping the great version divide. The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. 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
[Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de wrote: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? I personally consider getopt superior to both optparse and argparse. Those are terribly verbose in specifying arguments, whereas getopt's sequence-of-letters is really nice and compact. Thanks for the concrete example. Although I'm unconvinced that the characters you save in the sequence of letters in the getopt.getopt call aren't afterwards wasted on type conversions, if/else statements and variable assignments in the subsequent loop, it would be pretty simple to add to argparse something like:: ArgumentParser.add_getopt_arguments(options[, long_options]) Then you could replace your getopt code:: try: opts, args = getopt.getopt(sys.argv[1:], ho:v, [help, output=]) except getopt.GetoptError, err: # print help information and exit: print str(err) # will print something like option -a not recognized usage() sys.exit(2) output = None verbose = False for o, a in opts: if o == -v: verbose = True elif o in (-h, --help): usage() sys.exit() elif o in (-o, --output): output = a else: assert False, unhandled option with argparse code like:: parser = argparse.ArgumentParser() parser.add_getopt_arguments(ho:v, [help, output=]) args = parser.parse_args() verbose = args.v output = args.o or args.output If something like this were available, would you be alright with deprecating getopt? 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] Binary Operator for New-Style String Formatting
On Sun, Jun 21, 2009 at 1:36 PM, Jerry Chenj...@3rdengine.com wrote:
QUICK EXAMPLES
{} {} {} @ (1, 2, 3)
'1 2 3'
foo {qux} baz @ {qux: bar}
'foo bar baz'
One of the main complaints of a binary operator in PEP 3101 was the
inability to mix named and unnamed arguments:
The current practice is to use either a dictionary or a tuple as
the second argument, but as many people have commented ... this
lacks flexibility.
The other reason an operator was a pain is the order of operations:
'{0}'.format(1 + 2)
'3'
'%s' % 1 + 2
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: cannot concatenate 'str' and 'int' objects
In general, I don't see any gain in introducing an operator for string
formatting. What's the point? Maybe you save a few characters of
typing, but it sure is easier to Google for Python string format
than for Python @.
A big -1 from me.
Steve
--
Where did you get the 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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
On Sun, Apr 19, 2009 at 1:38 AM, Mart Sõmermaa mrts.py...@gmail.com wrote: On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan ncogh...@gmail.com wrote: That said, I'm starting to wonder if an even better option may be to just drop the kwargs support from the function and require people to always supply a parameters dictionary. That would simplify the signature to the quite straightforward: def add_query_params(url, params, allow_dups=True, sep='') That's the most straightforward and I like this more than the one below. I agree that isn't a good option, but mapping True/False/None to those specific behaviours also seems rather arbitrary (specifically, it is difficult to remember which of allow_dups=False and allow_dups=None means to ignore any duplicate keys and which means to ignore only duplicate items). I'd say it's less of a problem when using named arguments, i.e. you read it as: allow_dups=True : yes allow_dups=False : effeminately no :), allow_dups=None : strictly no which more or less corresponds to the behaviour. It also doesn't provide a clear mechanism for extension (e.g. what if someone wanted duplicate params to trigger an exception?) Perhaps the extra argument should just be a key/value pair filtering function, and we provide functions for the three existing behaviours (i.e. allow_duplicates(), ignore_duplicate_keys(), ignore_duplicate_items()) in the urllib.parse module. This would be the most flexible and conceptually right (ye olde strategy pattern), but would clutter the API. Note that your implementation and docstring currently conflict with each other - the docstring says pass them via a dictionary in second argument: but the dictionary is currently the third argument (the docstring also later refers to passing OrderedDictionary as the second argument). It's a mistake that exemplifies once again that positional args are awkward :). --- So, gentlemen, either def add_query_params(url, params, allow_dups=True, sep='') or def allow_duplicates(...) def remove_duplicate_values(...) ... def add_query_params(url, params, strategy=allow_duplicates, sep='') +1 for the strategy approach. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] #!/usr/bin/env python -- python3 where applicable
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan ncogh...@gmail.com wrote: Steven Bethard wrote: On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson benja...@python.org wrote: 2009/4/18 Nick Coghlan ncogh...@gmail.com: I see a few options: 1. Abandon the python name for the 3.x series and commit to calling it python3 now and forever (i.e. actually make the decision that Mitchell refers to). I believe this was decided on sometime (the sprints?). That's an unfortunate decision. When the 2.X line stops being maintained (after 2.7 maybe?) we're going to be stuck with the 3 suffix forever for the real Python. Why doesn't it make more sense to just use python3 only for altinstall and python for fullinstall? Note that such an approach would then require an altaltinstall command in order to be able to install a specific version of python 3.x without changing the python3 alias (e.g. installing 3.2 without overriding 3.1). I wasn't suggesting that there shouldn't be a python3.1, python3.2, etc. I'm more concerned about fullinstall creating python3 instead of regular python. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] #!/usr/bin/env python -- python3 where applicable
On Sat, Apr 18, 2009 at 10:04 PM, Nick Coghlan ncogh...@gmail.com wrote: Steven Bethard wrote: On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan ncogh...@gmail.com wrote: Note that such an approach would then require an altaltinstall command in order to be able to install a specific version of python 3.x without changing the python3 alias (e.g. installing 3.2 without overriding 3.1). I wasn't suggesting that there shouldn't be a python3.1, python3.2, etc. I'm more concerned about fullinstall creating python3 instead of regular python. If I understand Tony's summary correctly, the situation after Benjamin's latest checkin is as follows: 2.x altinstall: - installs python2.x executable 2.x fullinstall (default for make install): - installs python2.x executable - adjusts (or creates) python symlink to new executable 3.x altinstall (default for make install): - installs python3.x executable - adjusts (or creates) python3 symlink to new executable 3.x fullinstall: - installs python3.x executable - adjusts (or creates) python3 symlink to new executable - adjusts (or creates) python symlink to new executable Thanks for the clear explanation. The fact that python still appears with fullinstall covers my concern. With that setup, I'm sure we're going to get people complaining that 'altinstall' of 3.2 broke their python3 symlink from 3.1. If there are going to be 3 levels of executable naming (python3.x, python3, python), there needs to be 3 levels of installation rather than the traditional 2. For example, add a new target py3install and make that the default for 3.1: 3.x altinstall: - installs python3.x executable 3.x py3install (default for make install): - installs python3.x executable - adjusts (or creates) python3 symlink to new executable 3.x fullinstall: - installs python3.x executable - adjusts (or creates) python3 symlink to new executable - adjusts (or creates) python symlink to new executable Yep, I agree this is what needs done to sensibly support a python3. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa mrts.py...@gmail.com wrote:
On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Mart Sõmermaa mrts.pydev at gmail.com writes:
Proposal: add add_query_params() for appending query parameters to an
URL to
urllib.parse and urlparse.
Is there anything to /remove/ a query parameter?
I'd say this is outside the scope of add_query_params().
As for the duplicate handling, I've implemented a threefold strategy that
should address all use cases raised before:
def add_query_params(*args, **kwargs):
add_query_parms(url, [allow_dups, [args_dict, [separator]]], **kwargs)
Appends query parameters to an URL and returns the result.
:param url: the URL to update, a string.
:param allow_dups: if
* True: plainly append new parameters, allowing all duplicates
(default),
* False: disallow duplicates in values and regroup keys so that
different values for the same key are adjacent,
* None: disallow duplicates in keys -- each key can have a single
value and later values override the value (like dict.update()).
Unnamed flag parameters are unfriendly to the reader. If I see something like:
add_query_params(url, True, dict(a=b, c=d))
I can pretty much guess what the first and third arguments are, but I
have no clue for the second. Even if I have read the documentation
before, I may not remember whether the middle argument is allow_dups
or keep_dups.
Steve
:param args_dict: optional dictionary of parameters, default is {}.
:param separator: either ';' or '', the separator between key-value
pairs, default is ''.
:param kwargs: parameters as keyword arguments.
:return: original URL with updated query parameters or the original URL
unchanged if no parameters given.
The commit is
http://github.com/mrts/qparams/blob/b9bdbec46bf919d142ff63e6b2b822b5d57b6f89/qparams.py
extensive description of the behaviour is in the doctests.
___
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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa mrts.py...@gmail.com wrote: On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard steven.beth...@gmail.com wrote: On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa mrts.py...@gmail.com wrote: As for the duplicate handling, I've implemented a threefold strategy that should address all use cases raised before: def add_query_params(*args, **kwargs): add_query_parms(url, [allow_dups, [args_dict, [separator]]], **kwargs) Appends query parameters to an URL and returns the result. :param url: the URL to update, a string. :param allow_dups: if * True: plainly append new parameters, allowing all duplicates (default), * False: disallow duplicates in values and regroup keys so that different values for the same key are adjacent, * None: disallow duplicates in keys -- each key can have a single value and later values override the value (like dict.update()). Unnamed flag parameters are unfriendly to the reader. If I see something like: add_query_params(url, True, dict(a=b, c=d)) I can pretty much guess what the first and third arguments are, but I have no clue for the second. Even if I have read the documentation before, I may not remember whether the middle argument is allow_dups or keep_dups. Keyword arguments are already used for specifying the arguments to the query, so naming can't be used. Someone may need an 'allow_dups' key in their query and forget to pass it in params_dict. A default behaviour should be found that works according to most user's expectations so that they don't need to use the positional arguments generally. I believe the usual Python approach here is to have two variants of the function, add_query_params and add_query_params_no_dups (or whatever you want to name them). That way the flag parameter is named right in the function name. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] setuptools has divided the Python community
On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore p.f.mo...@gmail.com wrote: I use Python for systems admin scripts, Windows services, and database management. In my experience (and I agree, it's only one, limited, use case) availability of download-and-run bdist_wininst installers for every package I used was the only significant requirement I had for Python package distribution (I remember pre-distutils days, when being able to install a 3rd party package on Windows was a nightmare of build-it-yourself guesswork). Since setuptools came on the scene, I can state with some certainty that many packages which would otherwise have been distributed as bdist_wininst installers, now aren't. In some cases, only source packages are provided (on the basis that easy_install will build what you need). In those cases, I can accept that maybe the developer would not have built Windows installers even before setuptools arrived. But in a significant number of cases - including setuptools itself - binary, version-specific eggs for Windows are provided, but no bdist_wininst installers. If the developer is willing to build an egg, he could just as easily have built an installer - but he now has to choose - build one or the other, or both. And not everyone chooses the same way. I'd just like to chime in and agree with Paul here. I'm a Windows user, and I won't install a Python module that I can't get as a wininst (or preferably a .msi), because I prefer to use the Windows package management system, not some Python specific thing. I can generally build installers myself for Python-only packages, but binary ones are harder. And I've seen several projects with exactly the kind of thing Paul describes - where a good Windows installer would probably have been available if it weren't for the interference of setuptools. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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 377 - allow __enter__() methods to skip the statement body
On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum gu...@python.org wrote: Moreover, since the main use case seems to be fixing a corner case of the nested() context manager, perhaps the effort towards changing the language would be better directed towards supporting with a, b: as a shorthand for with a: with b: . On Mon, Mar 16, 2009 at 10:01 AM, Guido van Rossum gu...@python.org wrote: I have no right to speak because I haven't read through all the details of the proposal, but reading this I am very sad that we have to introduce a whole new exception (and one with special status as well) in order to fix such a niggly corner case of the context manager protocol. Since IIUC the original context manager design was intended to have exactly one yield in the body of the context manager -- can't we just declare fewer (or more) yields an error and rase an appropriate TypeError or something? It's not really a generator specific thing. You can generate similar problems by just defining a class with an __enter__() method that raises an exception. But I agree that it seems like a big change for a small corner case. Is there anything other than contextlib.nested() which needs this? If there is no other use case, then I'm a strong +1 for Guido's suggestion of providing syntactic support for ``with a, b:`` instead. BTW, I think the explanation of the problem isn't as clear as it could be. The core problem, if I understand it right, is that contextlib.nested() is not equivalent to a real nested with statement because it calls the nested __enter__() methods too early. A real nested with statement translates into something like:: mgr1.__enter__() try: mgr2.__enter__() try: BLOCK except: ... except: if not mgr1.__exit__(*sys.exc_info()): raise But contextlib.nested() calls all the __enter__() methods in its own __enter__() so it translates into something like:: mgr1.__enter__() mgr2.__enter__() try: BLOCK except: ... The key problem here is that ``mgr2.__enter__()`` is outside of the try block, and the context manager has no way to put it inside. So the thing that contextlib.nested() really needs is a way to be able to insert statements into the BLOCK part of the code. (I'm not actually suggesting we go this route, but that seems to be what contextlib.nested() is really after.) Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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 377 - allow __enter__() methods to skip the statement body
On Sun, Mar 15, 2009 at 10:50 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Brett Cannon wrote: Without knowing what StatementSkipped is (just some singleton? If so why not just used SkipStatement instance that was raised?) and wondering if we are just going to continue to adding control flow exceptions that directly inherit from BaseException or some ControlFlowException base class, the basic idea seems fine by me. Note that using exceptions for control flow can be bad for other implementations of Python. For example exceptions on the .NET framework are very expensive. (Although there are workarounds such as not really raising the exception - but they're ugly). Isn't it better practise for exceptions to be used for exceptional circumstances rather than for control flow? If my understanding is correct, the primary use case for this is when an exception is raised by an __enter__() method and caught by an enclosing __exit__() method. So at least in that case, you've already incurred the cost of an exception. It might be nice to see an example of this being used with only a single context manager. Is that possible? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Allow __enter__() methods to skip the with statement body?
On Wed, Feb 25, 2009 at 4:24 AM, Nick Coghlan ncogh...@gmail.com wrote: An interesting discrepancy [1] has been noted when comparing contextlib.nested (and contextlib.contextmanager) with the equivalent nested with statements. Specifically, the following examples behave differently if cmB().__enter__() raises an exception which cmA().__exit__() then handles (and suppresses): with cmA(): with cmB(): do_stuff() # This will resume here without executing Do stuff �...@contextlib.contextmanager def combined(): with cmA(): with cmB(): yield with combined(): do_stuff() # This will raise RuntimeError complaining that the underlying # generator didn't yield with contextlib.nested(cmA(), cmB()): do_stuff() # This will raise the same RuntimeError as the contextmanager # example (unsurprising, given the way nested() is implemented) The problem arises any time it is possible to skip over the yield statement in a contextlib.contextmanager based context manager without raising an exception that can be seen by the code calling __enter__(). If the problem is just the yield, can't this just be fixed by implementing contextlib.nested() as a class rather than as a @contextmanager decorated generator? Or is this a problem with class based context managers too? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Choosing a best practice solution for Python/extension modules
On Mon, Feb 23, 2009 at 04:02, Nick Coghlan ncogh...@gmail.com wrote:
For example, a version that allows any number of extension modules to be
suppressed when importing a module (defaulting to the Foo/_Foo naming):
import sys
def import_python_only(mod_name, *ext_names):
if not ext_names:
ext_names = ((_ + mod_name),)
orig_modules = {}
if name in sys.modules:
orig_modules[name] = sys.modules[name]
del sys.modules[name]
try:
for name in ext_names:
orig_modules[name] = sys.modules[name]
sys.modules[name] = 0
py_module = importlib.import_module(mod_name)
finally:
for name, module in orig_modules.items():
sys.modules[name] = module
return py_module
On Mon, Feb 23, 2009 at 11:05 AM, Brett Cannon br...@python.org wrote:
Well, neither do I as your proposed approach below is what I do for
warnings. But I think you and I, Nick, are more comfortable with mucking
with imports than most people. =) I think some people early on in this
thread said they didn't like the idea of screwing around with sys.modules.
But doing that along with an import * from the extension module is probably
the simplest solution.
+1 for something like Nick's code. No one has to know they're mucking
around with sys.modules - they just have to use the
import_python_only() function. (And I haven't seen anything in this
thread that's really any better.)
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] Challenge: Please break this! (was: Reviving restricted mode)
On Mon, Feb 23, 2009 at 12:10 PM, tav t...@espians.com wrote: Hey all, As an attempt to convince everyone of the merits of my functions-based approach to security, I've come up with a simple challenge. I've attached it as safelite.py The challenge is simple: * Open a fresh Python interpreter * Do: from safelite import FileReader * You can use FileReader to read files on your filesystem * Now find a way to *write* to the filesystem from your interpreter If you really want people to try and break it, I suggest you send it to c.l.py - there are load of people there with too much time on their hands. ;-) Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Choosing a best practice solution for Python/extension modules
On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon br...@python.org wrote:
But there is another issue with this: the pure Python code will never call
the extension code because the globals will be bound to _pypickle and not
_pickle. So if you have something like::
# _pypickle
def A(): return _B()
def _B(): return -13
# _pickle
def _B(): return 42
# pickle
from _pypickle import *
try: from _pickle import *
except ImportError: pass
If you import pickle and call pickle.A() you will get -13 which is not what
you are after.
Maybe I've missed this and someone else already suggested it, but
couldn't we provide a (probably C-coded) function
``replace_globals(module, globals)`` that would, say, replace the
globals in _pypickle with the globals in pickle? Then you could write
something like::
from _pypickle import *
try:
from _pickle import *
module = __import__('_pickle')
except ImportError:
module = __import__('_pypickle')
replace_globals(module, globals())
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] Attention Bazaar mirror users
On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore p.f.mo...@gmail.com wrote: PS Just for my own information, am I correct in thinking that it is *only* Bazaar in the (D)VCS world that has this problem, to any real extent? I know old Mercurial clients can interact with newer servers (ie, the wire protocol hasn't changed), I'm fairly sure that older Subversion clients can talk to newer servers (at least, I've never cared what client version I'm running). I've definitely had an SVN server tell me that I needed to upgrade my client to 1.5. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Duck-typing self
On Wed, Feb 18, 2009 at 2:32 PM, Sebastian Rittau srit...@jroger.in-berlin.de wrote: Hi! I am curious why the following will not work in Python: class foo(object): def bar(self): print self.attr class duck(object): attr = 3.14 foo.bar(duck()) Is it a design decision that duck-typing self does not work or is there a technical reason? From a practical standpoint it seems that being able to duck-type self has merit, for example in unit testing complex classes. Works for me in 3.0: Python 3.1a0 (py3k:69082, Jan 28 2009, 19:22:10) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. class Foo(object): ... def bar(self): ... print(self.attr) ... class Duck(object): ... attr = 3.14 ... Foo.bar(Duck()) 3.14 Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Missing operator.call
On Wed, Feb 4, 2009 at 10:25 AM, Brett Cannon br...@python.org wrote: On Wed, Feb 4, 2009 at 05:35, Hrvoje Niksic hrvoje.nik...@avl.com wrote: Andrew Bennetts wrote: A patch to add operator.caller(*args, **kwargs) may be a good idea. Your example would then be: map(operator.caller(), lst) Regarding the name, note that I proposed operator.call (and operator.__call__) because it corresponds to the __call__ special method, which is analogous to how operator.neg corresponds to __neg__, operator.add to __add__, etc. The term caller implies creation of a new object that carries additional state, such as method name in operator.methodcaller, item in operator.itemgetter, or attr in operator.attrgetter. Part of the problem is the term 'call' is an overloaded term. Do you really mean only objects that define __call__? What about objects that define __init__ and thus can be called as well? If you mean the former than you have to make sure the docs are very clear about this; there is a reason we got rid of callable(). If you mean the latter then there is little benefit to the function since ``[x() for x in lst]`` gets you the same result as your map call. Not sure I follow you here. It's not the __init__ that allows you to do ``x()``, it's the fact that the class declares a __call__, right? class C(object): ... pass ... C.__call__() __main__.C object at 0x01A3C370 C() __main__.C object at 0x02622EB0 str.__call__() '' str() '' That said, I'm also unconvinced of the utility of operator.call over the equivalent list comprehension. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Missing operator.call
On Wed, Feb 4, 2009 at 10:50 AM, Brett Cannon br...@python.org wrote: On Wed, Feb 4, 2009 at 10:43, Steven Bethard steven.beth...@gmail.com wrote: Not sure I follow you here. It's not the __init__ that allows you to do ``x()``, it's the fact that the class declares a __call__, right? class C(object): ... pass ... C.__call__() __main__.C object at 0x01A3C370 C() __main__.C object at 0x02622EB0 str.__call__() '' str() '' I don't think so:: Foo.__call__ method-wrapper '__call__' of type object at 0x81cee0c Foo.__call__ = lambda: None Foo.__call__ unbound method Foo.lambda Foo() __main__.Foo object at 0xf7f90e8c Take a look at PyObject_Call in abstract.c. Basically, __call__ is always looked up on the type, something like: class C(object): ... def __call__(self): ... return 'instance' ... def func(): ... return 'func' ... type(C).__call__(C) __main__.C object at 0x0263E250 type(C()).__call__(C()) 'instance' type(func).__call__(func) 'func' Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Python 3.0.1 (io-in-c)
On Wed, Jan 28, 2009 at 10:29 AM, Martin v. Löwis mar...@v.loewis.de wrote: Notice that the determination of the specific encoding used is fairly elaborate: - if IO is to a terminal, Python tries to determine the encoding of the terminal. This is mostly relevant for Windows (which uses, by default, the OEM code page in the terminal). - if IO is to a file, Python tries to guess the common encoding for the system. On Unix, it queries the locale, and falls back to ascii if no locale is set. On Windows, it uses the ANSI code page. On OSX, it uses the system encoding. - if IO is binary, (clearly) no encoding is used. Network IO is always binary. - for file names, yet different algorithms apply. On Windows, it uses the Unicode API, so no need for an encoding. On Unix, it (again) uses the locale encoding. On OSX, it uses UTF-8 (just to be clear: this applies to the first argument of open(), not to the resulting file object) This a very helpful explanation. Is it in the docs somewhere, or if it isn't, could it be? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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 374 (DVCS) now in reST
On Fri, Jan 23, 2009 at 12:06 PM, Martin v. Löwis mar...@v.loewis.de wrote:
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
Nice! So it's bzr, as my machine just told me (after adding
the square brackets).
Wow, that decision was a lot easier than I thought it would be. ;-)
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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 3142: Add a while clause to generator expressions
On Mon, Jan 19, 2009 at 7:10 AM, Gerald Britton gerald.brit...@gmail.com wrote: PEP: 3142 Title: Add a while clause to generator expressions [snip] numbers in that range. Allowing for a while clause would allow the redundant tests to be short-circuited: g = (n for n in range(100) while n*n 50) would also yield 0, 1, 2, 3, 4, 5, 6 and 7, but would stop at 8 since the condition (n*n 50) is no longer true. This would be equivalent to the generator function: def __gen(exp): for n in exp: if n*n 50: yield n else: break g = __gen(iter(range(100))) -1. As I pointed out on python-ideas, this proposal makes while mean something different in a generator expression. Currently, you can read any generator expression as a regular generator by simply indenting each clause and adding a yield statement. For example: (n for n in range(100) if n*n 50) turns into: for n in range(100): if n*n 50: yield n Applying that nice correspondence to the proposed while generator expression doesn't work though. For example: (n for n in range(100) while n*n 50) is, under the proposal, *not* equivalent to: for n in range(100): while n*n 50: yield n I'm strongly against making while mean something different in a generator expression than it does in a while statement. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] [Python-3000] New proposition for Python3 bytes filename issue
On Mon, Sep 29, 2008 at 6:07 AM, Victor Stinner [EMAIL PROTECTED] wrote: The default behaviour should be to use unicode and raise an error if conversion to unicode fails. It should also be possible to use bytes using bytes arguments and optional arguments (for getcwd). - listdir(unicode) - unicode and raise an error on invalid filename - listdir(bytes) - bytes - getcwd() - unicode - getcwd(bytes=True) - bytes Please let's not introduce boolean flags like this. How about ``getcwdb`` in parallel with the old ``getcwdu``? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] subprocess insufficiently platform-independent?
On Mon, Aug 25, 2008 at 11:30 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Aug 25, 2008, at 1:13 PM, Guido van Rossum wrote: Several people at Google seem to have independently discovered that despite all of the platform-independent goodness in subprocess.py, you still need to be platform aware. One of my colleagues summarized it like this: Given a straightforward command list like: cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk'] You apparently cannot pass this list to any subprocess function (subprocess.call() or otherwise) with a set of arguments that allow it to just work on both Windows and non-Windows systems. Unless I'm misremembering (I no longer have access to Windows), I believe that if you use ' '.join(cmd) as the first argument, it will work cross-platform. FWIW, I've also struggled with similar issues. For example, with no shell= argument, Windows typically opens up an extra window to run the command, while Unix doesn't. My most recent hack around this looked something like:: try: import win32con except ImportError: win32con = None kwargs = dict(...) if win32con is not None: kwargs['creationflags'] = win32con.CREATE_NO_WINDOW subprocess.Popen(cmd, **kwargs) I'd love to see subprocess become more consistent cross-platform. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] A smarter shutil.copytree ?
On Tue, Apr 22, 2008 at 1:56 AM, Tarek Ziadé [EMAIL PROTECTED] wrote:
On Mon, Apr 21, 2008 at 2:25 AM, Steven Bethard [EMAIL PROTECTED] wrote:
On Sun, Apr 20, 2008 at 4:15 PM, Tarek Ziadé [EMAIL PROTECTED] wrote:
I have submitted a patch for review here:
http://bugs.python.org/issue2663
glob-style patterns or a callable (for complex cases) can be provided
to filter out files or directories.
I'm not a big fan of the sequence-or-callable argument. Why not just
make it a callable argument, and supply a utility function so that you
can write something like::
exclude_func = shutil.excluding_patterns('*.tmp', 'test_dir2')
shutil.copytree(src_dir, dst_dir, exclude=exclude_func)
I made another draft based on a single callable argument to try out:
http://bugs.python.org/file10073/shutil.copytree.filtering.patch
The callable takes the src directory + its content as a list, and
returns filter eligible for exclusion
FWIW, that looks better to me.
That makes me wonder, like Alexander said on the bug tracker:
In the glob-style patterns callable, do we want to deal with absolute paths ?
I think that it would be okay to document that
shutil.ignore_patterns() only accepts patterns matching individual
filenames (not complex paths). If someone needs to do something with
absolute paths, then they can write their own 'ignore' function,
right?
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] [Distutils] how to easily consume just the parts of eggs that are good for you
On Wed, Apr 9, 2008 at 4:48 PM, Paul Moore [EMAIL PROTECTED] wrote: On 09/04/2008, Phillip J. Eby [EMAIL PROTECTED] wrote: It would be, if .eggs were a packaging format, rather than a binary distribution/runtime format. Remember eggs are to Python as jars are to Java -- a Java .jar doesn't contain documentation either, unless it's needed at runtime. Same for configuration files. And yet, Java doesn't have an equivalent of easy_install for jar files, to my knowledge. If Python had eggs but no easy_install, maybe this whole discussion wouldn't be taking place. (I know I personally like the idea of egg-as-jar-file, but *hate* the idea of egg-as-dependency-handling-tool-and-everything-else). So then do you really need anything more than the 2.6 support for executing directories (and zipfiles) with a __main__ file? $ python_d.exe --version Python 2.6a1+ $ more foo\__main__.py print 'here I am!' $ python_d.exe foo here I am! [8698 refs] $ python_d.exe foo.zip here I am! [8563 refs] STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] fixing tests on windows
On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy [EMAIL PROTECTED] wrote: Tim Golden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | [re tests which fail because something's holding a file | open with SHARE_DELETE] There are a couple of things one can do in a directory's Properties box (right click) to reduce interference. 1. Under General/Advanced, uncheck 'allow Indexing Service' and click Yes to recursively apply to subdirs and files. 2. Under Sharing, check 'Make private'. This is recursive, but only works for dirs under My Documents or on Desktop. This would be most useful, I think, if buildbots run as a separate user. Have these already been done? We already know how to stop the errors from arising by modifying the Windows environment. In my particular case, it was sufficient to disable Windows Search Service and the TortoiseSVN Image Overlays. However, it would be *really* nice if the Python test suite just worked out of the box, and you didn't have to change your normal Windows environment. Or were you suggesting that there is some programmatic way for the test suite to create directories that disallow the Search Service, etc.? Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] fixing tests on windows
On Tue, Apr 1, 2008 at 12:42 AM, Neal Norwitz [EMAIL PROTECTED] wrote: The Windows buildbots are still failing because some tests keep files opened. This causes subsequent tests which use the same file to fail. Here is a recent run which had a failure early on: http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1209/step-test/0 I'm assuming the first failure (test_bufio) was due to an open file. (Can't tell, no error msg.) That means the problem was in that test or an earlier test. The only earlier tests are: test_import test_sys test_descr test_xdrlib test_urllibnet test_binhex test_strptime test_importhooks test_copy test_hmac test_genericpath test_complex test_timeout test_quopri test_marshal test_zipfile test_mutants test_csv test_ucn test_hash test_wsgiref test_mmap test_ftplib test_pickletools test_codecmaps_cn Of those tests, only some of them reference TESTFN which is the probable file: test_import 22 test_descr 3 test_urllibnet 2 test_binhex 2 test_genericpath 44 test_complex 3 test_marshal 33 test_zipfile 136 test_mutants 7 test_mmap 32 I inspected test_mmap which had been modified somewhat recently and tried to fix a few things. I'm not sure I helped and there are probably more problems lurking. This issue may not be noticed in the default test run. It definitely occurs when the tests are run in a random order as they are on the buildbots. Try running: ./python.exe ./Lib/test/regrtest.py -r That should help provoke more errors. At the sprints, I ran into a bunch of similar errors running the test suite on my Windows Vista box, even on tests that were properly cleaning up after themselves in tearDown(). I even tried putting in sleeps as long as 1 second, to no avail. The only way to get the test suite to run without these errors was to stop the Windows Search Service, fully disable Icon Overlays for TortoiseSVN, and then close down all open folders. Any chance the boxes the tests are being run on are running the Windows Search Service or have Icon Overlays enabled for TortoiseSVN? (If anyone has any ideas of how to get around these problems, I'd love to hear them. Seems like I shouldn't have to disable these services.) Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] fixing tests on windows
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista [EMAIL PROTECTED] wrote: 2008/4/1, Tim Golden [EMAIL PROTECTED]: If this is the thing to do, presumably test_support should grow a remove_file which does something of this sort? +1 (I was thinking exactly that). +1 here too. That looks like a great solution. Of course, once it's in test_support, we need to fix *all* file removals in the test suite. ;-) Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Making sys.py3k_warning writable
On Sat, Mar 22, 2008 at 2:58 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: Steven Bethard wrote: Right now, test_py3kwarn only runs if the test suite is run using the -3 command line flag to Python. So for most regrtest runs (e.g. the buildbots) this test will never be run. For the buildbots, it would be easy to turn -3 on, though. Right now, running the test suite with -3 spews a load of warnings since there is a lot of code that hasn't been updated for even simple things like ``dict.has_key``. Would turning the -3 flag on make it too hard to diagnose problems? If people don't think so, I'm happy to have it turned on. I did find a minor bug in the test suite when I turned it on and ran the full regrtest. On Sat, Mar 22, 2008 at 3:29 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: [http://bugs.python.org/issue2458] Thanks for putting that together! Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Fixing code that produces -3 warnings in the Python 2.6 stdlib
On Sun, Mar 23, 2008 at 3:02 PM, Martin v. Löwis wrote: [talking about running the buildbots using the -3 flag to issue Py3K warnings] Yes. I don't think it should be turned on regularly in the tests until they regularly are quiet under -3. So the plan is to silence all Py3K warnings in the Python 2.6 stdlib? I'd like to see this happen, but I vaguely remembered some people being against this idea, so I'd like to make sure. For what it's worth, I started an issue for this earlier: http://bugs.python.org/issue2402 Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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
