On Wed, Feb 18, 2009 at 2:32 PM, Sebastian Rittau
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
On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore 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 cha
On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon 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()
> de
On Mon, Feb 23, 2009 at 04:02, Nick Coghlan 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:
>e
On Mon, Feb 23, 2009 at 12:10 PM, tav 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
> *
On Wed, Feb 25, 2009 at 4:24 AM, Nick Coghlan 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__() r
On Sun, Mar 15, 2009 at 10:50 AM, Michael Foord
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
On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum 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
On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore 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
On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
>
>
> On Mon, Apr 13, 2009 at 12:56 AM, Antoine Pitrou
> wrote:
>>
>> Mart Sõmermaa gmail.com> writes:
>> >
>> > Proposal: add add_query_params() for appending query parameters to an
>> > URL to
>> urllib.parse and urlparse.
>>
>> Is there an
On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa wrote:
> On Mon, Apr 13, 2009 at 8:23 PM, Steven Bethard
> wrote:
>> On Mon, Apr 13, 2009 at 2:29 AM, Mart Sõmermaa wrote:
>> > As for the duplicate handling, I've implemented a threefold strategy that
>> >
On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson wrote:
> 2009/4/18 Nick Coghlan :
>> 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
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
> Steven Bethard wrote:
>> On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson
>> wrote:
>>> 2009/4/18 Nick Coghlan :
>>>> I see a few options:
>>>> 1. Abandon the "python" name for
On Sat, Apr 18, 2009 at 10:04 PM, Nick Coghlan wrote:
> Steven Bethard wrote:
>> On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
>>> Note that such an approach would then require an altaltinstall command
>>> in order to be able to install a specific ve
On Sun, Apr 19, 2009 at 1:38 AM, Mart Sõmermaa wrote:
> On Sun, Apr 19, 2009 at 2:06 AM, Nick Coghlan 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. Th
On Sun, Jun 21, 2009 at 1:36 PM, Jerry Chen 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:
>
/
--
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
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 25-Sep-2009
Python-Version: 2.7 and 3.2
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou 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
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> 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 plea
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> 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
On Sun, Sep 27, 2009 at 9:09 PM, "Martin v. Löwis" 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 superio
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson
>> wrote:
>>> 2009/9/27 Steven Bethard :
>>>> The first release where any real deprecation message would show up i
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens
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
On Mon, Sep 28, 2009 at 4:09 AM, Neal Becker 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
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
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 h
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano 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_argumen
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon wrote:
> On Mon, Sep 28, 2009 at 08:49, Steven Bethard
> wrote:
>> On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano wrote:
>>> On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
>>>> * Would you like ar
On Mon, Sep 28, 2009 at 8:44 PM, "Martin v. Löwis" 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
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore wrote:
> 2009/9/28 Yuvgoog Greenle :
>> 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 wor
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman 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 ha
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("%(a
On Tue, Sep 29, 2009 at 5:54 PM, Benjamin Peterson 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
On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan 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 getop
On Tue, Sep 29, 2009 at 8:15 PM, "Martin v. Löwis" wrote:
> Steven Bethard wrote:
>> Consider an example from the logging
>> docs:
>>
>> logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
>>
>> We'
On Tue, Sep 29, 2009 at 10:04 PM, James Y Knight 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) ==
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw 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
On Wed, Sep 30, 2009 at 8:31 AM, Barry Warsaw wrote:
> On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:
>> On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw wrote:
>>> On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
>>>> I would propose that the format
On Wed, Sep 30, 2009 at 8:50 AM, Barry Warsaw 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
>&g
On Wed, Sep 30, 2009 at 1:17 PM, Andrew McNabb 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
On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon 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, coll
On Thu, Oct 1, 2009 at 4:35 PM, Brett Cannon wrote:
> On Thu, Oct 1, 2009 at 15:19, Steven Bethard wrote:
>> On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon wrote:
>>> class braces_fmt(str):
>>>
>>> def __mod__(self, stuff):
>>> if isinsta
On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy 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 cla
On Fri, Oct 2, 2009 at 2:34 AM, Antoine Pitrou wrote:
> Steven Bethard 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 be
On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler 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?
On Fri, Oct 2, 2009 at 11:56 AM, Raymond Hettinger 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 ha
On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle 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
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 ac
On Sat, Oct 3, 2009 at 8:17 AM, Michael Foord wrote:
> Steven Bethard wrote:
>> On Sat, Oct 3, 2009 at 3:45 AM, Yuvgoog Greenle
>> wrote:
>>> I haven't checked if it's possible, but I suggest Argparse have it's
>>> own exception class that inherits
On Sun, Oct 11, 2009 at 9:52 AM, Paul Moore wrote:
> 2009/10/9 Michael Foord :
>> 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 Wind
On Tue, Oct 20, 2009 at 7:44 PM, David Cournapeau wrote:
> On Wed, Oct 21, 2009 at 5:49 AM, Paul Moore wrote:
>> 2009/10/20 Chris Withers :
>> 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 yo
se.
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
Status: Draft
Type: Standards Track
Content-Type: text/x-r
On Sat, Oct 24, 2009 at 4:34 PM, Ben Finney wrote:
> Steven Bethard writes:
>
>> Discussion: sys.err and sys.exit
>>
>> There were some concerns that argparse by default always writes to
>> ``sys.err``
> […]
>
> Unless, I&#
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw 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 fe
On Tue, Nov 3, 2009 at 6:14 AM, Daniel Stutzbach
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 th
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
* Br
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote:
> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
> 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 scrip
On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang 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
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang 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
On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang wrote:
> On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan wrote:
>>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang wrote:
I thought that one of the following approaches would be considered :
1 - let optparse remain in stdlib (as is or not ...)
On Mon, Dec 14, 2009 at 4:16 PM, sstein...@gmail.com
wrote:
>
> On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:
>
>> Michael Foord 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
On Tue, Dec 15, 2009 at 4:33 AM, Neal Becker 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:
>> unsu
On Sun, Dec 27, 2009 at 9:51 AM, anatoly techtonik wrote:
> On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
> 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
>
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw 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
On Wed, Jan 13, 2010 at 9:40 AM, Ralf Schmitt wrote:
> "R. David Murray" writes:
>
>> Please review issue 2375 [1], which is an enhancement request to add a
>> PYTHON3PATH environment variable. Because we have elected to have both
>> a python and a python3 command, I think this is an issue worth
On Fri, Feb 19, 2010 at 7:50 AM, Brett Cannon 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 Hiphopopo
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 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
On Sun, Feb 21, 2010 at 10:31 AM, Guido van Rossum wrote:
> On Sun, Feb 21, 2010 at 1:26 PM, Steven Bethard
> wrote:
>> So basically do what the PEP does now, except don't remove optparse in
>> Python 3.5? For reference, the current proposal is:
>>
>> * Py
On Fri, Mar 5, 2010 at 10:51 AM, Neal Becker wrote:
> I generally enjoy argparse, but one thing I find rather
> ugly and unpythonic.
>
> parser.add_argument ('--plot', action='store_true')
>
> Specifying the argument 'action' as a string is IMO ugly.
If it really bothers you, you can use:
On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum wrote:
> On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker wrote:
>> Brian Curtin wrote:
>>
>>> On Fri, Mar 5, 2010 at 12:51, Neal Becker wrote:
>>>
I generally enjoy argparse, but one thing I find rather
ugly and unpythonic.
par
On Mon, Mar 8, 2010 at 7:40 AM, Steven Bethard wrote:
> On Sun, Mar 7, 2010 at 11:49 AM, Guido van Rossum wrote:
>> On Sun, Mar 7, 2010 at 4:29 AM, Neal Becker wrote:
>>> Brian Curtin wrote:
>>>
>>>> On Fri, Mar 5, 2010 at 12:51, Neal Becker wrote:
>
On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc
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
On Wed, Mar 24, 2010 at 10:08 AM, Brett Cannon wrote:
> On Wed, Mar 24, 2010 at 09:05, Steven Bethard
> wrote:
>> On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc
>> wrote:
>> > I noticed that the newly added argparse module has an unusual
>> > li
On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp 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
On Sun, Apr 18, 2010 at 4:03 AM, Nick Coghlan 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"
On Sun, Apr 18, 2010 at 2:35 PM, Tobias Herp wrote:
> Steven Bethard schrieb:
>> On Sun, Apr 18, 2010 at 3:31 AM, Tobias Herp wrote:
>>> *Argparse should simply do this like optparse does already.*
>>> I.e., use '--version', '--help' and &
On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan 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
>> 've
On Sun, Apr 18, 2010 at 3:52 PM, Antoine Pitrou wrote:
> Steven Bethard 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 stri
On Sun, Apr 18, 2010 at 4:35 PM, Nick Coghlan wrote:
> Steven Bethard wrote:
>> On Sun, Apr 18, 2010 at 3:57 PM, Nick Coghlan wrote:
>>> Steven Bethard wrote:
>>>> By the way, we could simplify the typical add_argument usage by adding
>>>> "show pr
On Sun, Apr 18, 2010 at 6:40 PM, Nick Coghlan 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 th
On Sun, Apr 18, 2010 at 7:02 PM, Ian Bicking 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
On Mon, Apr 19, 2010 at 12:51 PM, Michael Foord
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
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
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
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
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
On Tue, Sep 21, 2010 at 3:46 PM, Michael Foord
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
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 publ
On Mon, Nov 1, 2010 at 2:53 PM, Michael Foord 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
On Mon, Nov 1, 2010 at 2:57 PM, Guido van Rossum wrote:
> On Mon, Nov 1, 2010 at 7:53 AM, Michael Foord
> 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 jus
On 7/14/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote:
> > (add PEP announcements and python-dev summary items to the mix, and you
> > have a high-quality development blog generated entirely from existing
> > content)
> > (hmm. maybe
Here's the draft for the second half of June. As always, comments and
corrections are greatly appreciated.
=
Announcements
=
---
Python 2.5 schedule
---
A number of bugs are being squashed as Python 2.5 moves towards its
next release. Se
Here's the summary for the first half of July. Corrections and
comments are greatly apprecieated. Particularly for the section on
restricted execution (though my understanding is that the current
plans are somewhat different than what was discussed during the first
half of July).
=
Ann
Here's the summary for the second half of July. Thanks in advance for
your comments and corrections!
=
Announcements
=
---
Python 2.5 schedule
---
After inserting a third beta release to allow some more time for
testing the new features, P
Sorry about the delay. Here's the summary for the first half of
August. As always, comments and corrections are greatly appreciated.
=
Summaries
=
Mixing str and unicode dict keys
Ralf Schmitt noted that in Pyth
Here's the draft summary for the second half of August. As always,
comments and corrections are greatly appreciated!
=
Announcements
=
---
Python communnity buildbots
---
Want to make sure your package works with the lates
Here's the summary for the first half of September. As always,
comments and corrections are greatly appreciated!
=
Announcements
=
QOTF: Quote of the Fortnight
Through a cross-posting slip-up, Jean-Paul Calderone
Thanks to all of those who have already given me feedback on the last
summary. Here's the next one (for the second half of September). I
found the "OS X universal binaries" and "Finer-grained locking than
the GIL" discussions particularly hard to follow, so I'd especially
appreciate corrections o
Here's the summary for the second half of October. Comments and
corrections welcome as always, especially on that extended buffer
protocol / binary format specifier discussion which was a little
overwhelming. ;-)
=
Announcements
=
--
R
Here's the summary for the first half of November. Try not to spend it
all in one place! ;-)
As always, corrections and comments are greatly appreciated.
=
Announcements
=
--
Python 2.5 malloc families
--
Just a reminder t
Here's the summary for the second half of November. As always,
corrections and comments are greatly appreciated. If you were
involved in the November portions of the LSB discussions, I'd
particularly appreciate your reviews of that section.
=
Announcements
=
1 - 100 of 320 matches
Mail list logo
