Re: [Python-Dev] argparse ambiguity handling
Cameron Simpson wrote: On 20Apr2010 15:27, Neal Becker wrote: | Steven Bethard wrote: | | > On Tue, Apr 20, 2010 at 11:55 AM, Neal Becker 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 | | At least 1 earlier version said that even exact match was ambiguous. | | I have a preference to allow at least exact matches to succeed even in the | case of ambiguity - mainly because I accidentally created this already once, | and I feel it's better to at least work somewhat. Not sure if there is any | more elegant solution. OTOH, I feel this is somewhat inelegant, as it | appears to treat exact match as a special case. I think the new behaviour is desirable. Plenty of commands have both --foo and --foo-tweak. Usually because --foo came first and --foo-tweak came later, or simply because --foo is the simple and obvious and commonly wanted mode and --foo-tweak is a special case. Real world example: rsync and the --delete* options. I'm sure plenty of others can be found. The new behaviour makes this doable. The old behaviour made it unimplementable. Maybe it is desirable to be _able_ to forbid this arguably-ambiguous option set, but I definitely feel that the current behaviour should be available. 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. Eric. ___ 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 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 ___ 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 328, relative imports and Python 2.7
While talking about Python 2.6 -> 2.7 transitions, the subject of relative and absolute imports has come up. PEP 328 states that absolute imports will be enabled by default in Python 2.7, however I cannot verify that this has actually happened. * Misc/NEWS doesn't mention it * What's New in Python 2.7 doesn't mention it either * My own limited testing on trunk indicates it hasn't happened Now, truth be told I only spent 15 minutes investigating this so I could certainly have missed something. Are absolute imports enabled by default in Python 2.7? If not, given that we're into beta, I don't think we can do it now, so I would suggest updating the PEP. If they have been enabled then we need to update NEWS and What's New. -Barry signature.asc Description: PGP signature ___ 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
Tobias Herp wrote: > > What /is/ this ambiguity of the "version=" argument? There is none! > > Do it the way optparse does it, and all is fine! All is not fine. How do I add a "-V" shortcut that is equivalent to "--version" as part of an optparse program? (That's a real question, I honestly have no idea how I would do that short of writing my own version display option). Since argparse now uses action='version' instead, the same question becomes trivial (just list "-V" as one of the accepted options for that action). There are at least three reasonable approaches for version options (ignoring the fact that Windows users expect their options to start with a '/' instead of a '-'): - just "--version" (the optparse way) - "-V" and "--version" (the Python interpreter way) - "-v" and "--version" (the old argparse way) The third is by far the least common of the three, but even you admit both of the first two are quite common and acceptable according to the de facto "standard". Optparse makes it easy to do it the optparse way, but difficult to support either of the other formats. Argparse used to be in a similar boat, where only the third option was easy. The latest argparse approach is straightforward regardless of the particular spelling you happen to prefer. Since getting away from the "thou shalt" preachiness of optparse is one of the big reasons for adding argparse in the first place, it seems odd to complain when it switches to a more consistent and flexible API. There were a couple of issues to be addressed with the implementation and the documentation, but the basic approach is sound. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328, relative imports and Python 2.7
On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote: > While talking about Python 2.6 -> 2.7 transitions, the subject of relative and > absolute imports has come up. PEP 328 states that absolute imports will be > enabled by default in Python 2.7, however I cannot verify that this has > actually happened. I'm fairly sure it hasn't. I brought this up on python-dev in February (around Feb 2nd; thread entitled 'Absolute imports in Python 2.x'), but for some reason I can only find the tail end of that thread on mail.python.org: http://mail.python.org/pipermail/python-dev/2010-February/097458.html > Python 2.7? If not, given that we're into beta, I don't think we can do it > now, so I would suggest updating the PEP. Agreed. There's also the question of whether deprecation warnings or -3 warnings should be raised; see http://bugs.python.org/issue7844 Mark ___ 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 328, relative imports and Python 2.7
On Wed, Apr 21, 2010 at 2:56 PM, Mark Dickinson wrote: > On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote: >> While talking about Python 2.6 -> 2.7 transitions, the subject of relative >> and >> absolute imports has come up. PEP 328 states that absolute imports will be >> enabled by default in Python 2.7, however I cannot verify that this has >> actually happened. > > I'm fairly sure it hasn't. I brought this up on python-dev in > February (around Feb 2nd; thread entitled 'Absolute imports in Python > 2.x'), but for some reason I can only find the tail end of that thread > on mail.python.org: > > http://mail.python.org/pipermail/python-dev/2010-February/097458.html Ah, here's a better link to a different archive of the previous discussion. http://www.mail-archive.com/python-dev@python.org/msg45275.html Mark ___ 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] jean-claude elias
http://www.aricciafestaecultura.it/home.php ___ 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] Email addresses for new committers for python-committers
I'm already subscribed as "g.rod...@gmail.com" and I'm able to receive messages from the list. 2010/4/20 Brett Cannon : > If you are a committer and are NOT subscribed to the python-committers > mailing list (I believe this at least includes Giampaolo, JP, and Brian), > then please either reply to this email with your preferred email address or > let me know directly (the former is preferred so Georg or Eric can beat me > to the subscription if I take too long). > ___ > 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/g.rodola%40gmail.com > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Small suggestion re help(Exception)
help() on an Exception class lists the method resolution order (effectively the inheritance hierarchy). E.g. help(ArithmeticError) displays inter alia: Method resolution order: ArithmeticError StandardError Exception BaseException __builtin__.object Would it be possible for it also display the Python built-in SUBclasses of the class? E.g. in the same example something like: Built-in subclasses: FloatingPointError OverflowError ZeroDivisionError This may seem pointless to grizzled old Python veterans who (maybe) know the inheritance hierarchy backwards, but for those of us with less experience I think it would be helpful, e.g. (1) It would help to track down an Exception whose name you have forgotten. (2) It would sometimes be illuminating, e.g. LookupError might be a bit obscure at first, until you see that it is the superclass of the familiar IndexError and KeyError. Sorry, I'm not sure if I should send this sort of thing to Python-Ideas or Python-Dev, so please let me know gently which one I should (not) have sent it to. Best wishes Rob Cliffe___ 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] Small suggestion re help(Exception)
On 21/04/2010 18:17, Rob Cliffe wrote: help() on an Exception class lists the method resolution order (effectively the inheritance hierarchy). E.g. help(ArithmeticError) displays inter alia: Method resolution order: ArithmeticError StandardError Exception BaseException __builtin__.object Would it be possible for it also display the Python built-in SUBclasses of the class? E.g. in the same example something like: Built-in subclasses: FloatingPointError OverflowError ZeroDivisionError This may seem pointless to grizzled old Python veterans who (maybe) know the inheritance hierarchy backwards, but for those of us with less experience I think it would be helpful, e.g. (1) It would help to track down an Exception whose name you have forgotten. (2) It would sometimes be illuminating, e.g. LookupError might be a bit obscure at first, until you see that it is the superclass of the familiar IndexError and KeyError. Sorry, I'm not sure if I should send this sort of thing to Python-Ideas or Python-Dev, so please let me know gently which one I should (not) have sent it to. This sounds like a pretty straightforward feature request that you could put on the tracker (preferably with patch and tests of course), but is on-topic for this mailing list. I rarely use help(...) myself (I probably should), but it sounds like a useful enhancement. Michael Best wishes Rob Cliffe ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ 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 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] Small suggestion re help(Exception)
- Original Message - From: "Aurélien Campeas" To: "Rob Cliffe" Sent: Wednesday, April 21, 2010 5:25 PM Subject: Re: [Python-Dev] Small suggestion re help(Exception) > like in > ArithmeticError.__subclasses__() > [, 'exceptions.OverflowError'>, ] > > ? Yes, exactly like that. I wasn't aware of __subclasses__ (it doesn't appear in dir(ArithmeticError), for example), but if my suggestion were adopted, __subclasses__ would be just what is needed to implement it. Rob Cliffe > > Le mercredi 21 avril 2010 à 17:17 +0100, Rob Cliffe a écrit : >> help() on an Exception class lists the method resolution order >> (effectively the inheritance hierarchy). >> E.g. help(ArithmeticError) displays inter alia: >> >> Method resolution order: >> ArithmeticError >> StandardError >> Exception >> BaseException >> __builtin__.object >> >> Would it be possible for it also display the Python built-in >> SUBclasses of the class? E.g. in the same example something like: >> >> Built-in subclasses: >> FloatingPointError >> OverflowError >> ZeroDivisionError >> >> This may seem pointless to grizzled old Python veterans who (maybe) >> know the inheritance hierarchy backwards, but for those of us with >> less experience I think it would be helpful, e.g. >> (1) It would help to track down an Exception whose name you have >> forgotten. >> (2) It would sometimes be illuminating, e.g. LookupError might be a >> bit obscure at first, until you see that it is the superclass of the >> familiar IndexError and KeyError. >> >> Sorry, I'm not sure if I should send this sort of thing to >> Python-Ideas or Python-Dev, so please let me know gently which one I >> should (not) have sent it to. >> >> Best wishes >> Rob Cliffe >> ___ >> 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/aurelien.campeas%40logilab.fr > > ___ 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 328, relative imports and Python 2.7
On Wed, Apr 21, 2010 at 06:58, Mark Dickinson wrote: > On Wed, Apr 21, 2010 at 2:56 PM, Mark Dickinson > wrote: > > On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote: > >> While talking about Python 2.6 -> 2.7 transitions, the subject of > relative and > >> absolute imports has come up. PEP 328 states that absolute imports will > be > >> enabled by default in Python 2.7, however I cannot verify that this has > >> actually happened. > > > > I'm fairly sure it hasn't. I brought this up on python-dev in > > February (around Feb 2nd; thread entitled 'Absolute imports in Python > > 2.x'), but for some reason I can only find the tail end of that thread > > on mail.python.org: > > > > http://mail.python.org/pipermail/python-dev/2010-February/097458.html > > Ah, here's a better link to a different archive of the previous discussion. > > http://www.mail-archive.com/python-dev@python.org/msg45275.html And it looks like it mostly got hijacked by a discussion of how to keep track of long-term issues. =) As for changing the semantics of this, I would love to see it happen, but as Barry said, into a beta probably means no. So we should at least add a Py3K warning (if there isn't one already) as implicit relative imports cannot be guaranteed correct by 2to3 in the face of ambiguity. Plus the silencing of DeprecationWarnings by default means it won't trigger more noise for users. ___ 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 328, relative imports and Python 2.7
On Apr 21, 2010, at 02:56 PM, Mark Dickinson wrote: >On Wed, Apr 21, 2010 at 2:40 PM, Barry Warsaw wrote: >> While talking about Python 2.6 -> 2.7 transitions, the subject of relative >> and >> absolute imports has come up. PEP 328 states that absolute imports will be >> enabled by default in Python 2.7, however I cannot verify that this has >> actually happened. > >I'm fairly sure it hasn't. I brought this up on python-dev in >February (around Feb 2nd; thread entitled 'Absolute imports in Python >2.x'), but for some reason I can only find the tail end of that thread >on mail.python.org: > >http://mail.python.org/pipermail/python-dev/2010-February/097458.html > >> Python 2.7? If not, given that we're into beta, I don't think we can do it >> now, so I would suggest updating the PEP. > >Agreed. There's also the question of whether deprecation warnings or >-3 warnings should be raised; see > >http://bugs.python.org/issue7844 For the time being, I've removed the sentence from the PEP that says absolute imports will be enabled by default in Python 2.7. -Barry signature.asc Description: PGP signature ___ 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] Reject bytearray filename in Python 3.2
Hi, About my work on unicode surrogates, I would like to reject bytearray filename, especially in the PyUnicode_FSConverter function. As explained in issue #8485, support bytearray requires to test the result type, acquire/release a lock, the API is more complex, etc. I don't know real world usecase of bytearray filename. The os.path module doesn't support it and no Python 3.0 or 3.1 user noticed that. Support of bytearray in not documentation in PyUnicode_FSConverter() comment (Include/unicodeobject.h). Martin Loewis, the author of PEP 383, created PyUnicode_FSConverter() and he agree to drop support of bytearray filename. But he asked me to ask on this mailing list if anyone would prefer to mark bytearray filename as deprecated in 3.2 and reject them in 3.3. I will be very sad if someone ask me to keep bytearray filename support in 3.2 because I opened a lot of issues about surrogates and I would make my work more diffcult :-( -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small suggestion re help(Exception)
Rob Cliffe wrote: > Yes, exactly like that. > I wasn't aware of __subclasses__ (it doesn't appear in > dir(ArithmeticError), > for example) Slight tangent: dir() usually includes class attributes (e.g. "set(dir(1)) >= set(dir(int))"), but to prevent weirdness that particular feature is omitted for the metaclass of a type. So dir(type(cls)) may reveal a few extra methods/properties (such as mro() and __subclasses__()) that aren't listed when doing dir(cls). > but if my suggestion were adopted, __subclasses__ would be > just what is needed to implement it. Restricting it to just builtins would be tricky, especially for Exception (even without importing any additional libraries, Exception.__subclasses__() lists 23 direct subclasses at the interpreter prompt for me). Anyway, as Michael suggested, a feature request on the bugs.python.org tracker is the best way forward. That's no guarantee that anyone will pick it up and run with it, but at least it will record the idea. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reject bytearray filename in Python 3.2
Victor Stinner wrote: > I will be very sad if someone ask me to keep bytearray filename support in > 3.2 > because I opened a lot of issues about surrogates and I would make my work > more diffcult :-( I don't have an opinion one way or the other regarding bytearray, but even if you deprecated it rather than dropping it, couldn't you just add the surrogate support for the Unicode path and leave the bytecode path with the legacy behaviour? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reject bytearray filename in Python 3.2
Le jeudi 22 avril 2010 00:21:02, vous avez écrit : > Victor Stinner wrote: > > I will be very sad if someone ask me to keep bytearray filename support > > in 3.2 because I opened a lot of issues about surrogates and I would make > > my work more diffcult :-( > > I don't have an opinion one way or the other regarding bytearray, but > even if you deprecated it rather than dropping it, couldn't you just add > the surrogate support for the Unicode path and leave the bytecode path > with the legacy behaviour? Yes, we can do everything. But does it really have a sense? No Python function using filenames return a bytearray object. Example: os.listdir() and os.walk() result type is bytes or str. Changing PyUnicode_FSConverter() is trivial, but the problem is in the function calling PyUnicode_FSConverter(). The caller have to support byte and bytearray. Antoine proposed to convert bytearray to bytes to ensure that PyUnicode_FSConverter() result is a bytes object. But in this case, we still need also to fix ntpath, ,posixpath and macpath modules to support bytearray. -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
