[Python-Dev] transitioning from % to {} formatting

Steven Bethard steven.bethard at gmail.com
Wed Sep 30 19:14:17 CEST 2009


On Wed, Sep 30, 2009 at 8:50 AM, Barry Warsaw <barry at 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


More information about the Python-Dev mailing list