Bugbee, Larry wrote:
> So until I see a *significant* benefit, my vote is *not* remove
> %-formatting. Make both available and if {} is to win, it will.
Percent formatting isn't going anywhere (certainly not for the next
decade or so). However, its well documented limitations (especially the
lack
2009/10/3 Brett Cannon :
> On Fri, Oct 2, 2009 at 20:03, Raymond Hettinger wrote:
>>
>> [Terry Reedy]
>>>
>>> I would agree, for instance, that an auto-translation tool is needed.
>>
>> We should get one written. ISTM, every %-formatting
>> string is directly translatable to an equivalent {}-form
On Wed, Sep 30, 2009 at 5:15 PM, Yuvgoog Greenle wrote:
> I like how python has a minimalistic and powerful syntax (-1 for the break
> ___ PEP).
> Also, I really dislike the for/else ambiguity "butterflies".
> When is the else after a loop executed? 1. When the loop isn't entered at
> all.
> 2. Wh
On Sun, 4 Oct 2009 08:21:46 am Robert Kern wrote:
> There are uses of argparse outside of command line apps. For example,
> I use it to parse --options for IPython %magic commands. Of course, I
> just subclass ArgumentParser and replace the .error() method.
Exactly. There are uses for catching Sy
On Sun, 4 Oct 2009 05:35:04 am André Malo wrote:
> * Steven D'Aprano wrote:
> > You don't need a comment warning that you are catching SystemExit
> > because parse_args raises SystemExit, any more than you need a
> > comment saying that you are catching ValueError because some
> > function raises V
Terry Reedy wrote:
Steven Bethard wrote:
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.
definitely
The basic problem is that many APIs in the standard library and
elsewhere support only %-
MRAB mrabarnett.plus.com> writes:
> Interesting that you're using the %-format to translate %-formats to
> {}-formats!
Yes, ironic, isn't it? ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Vinay Sajip wrote:
Brett Cannon python.org> writes:
Why don't we start something in the sandbox and see how far we can
get. If no one beats me to it I will add the directory some time today
and we can start hashing out the solution there.
I've done a first cut of a converter from %-format t
Steven Bethard wrote:
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.
definitely
The basic problem is that many APIs in the standard library and
elsewhere support only %-formatting and not {
2009/10/3 Vinay Sajip :
> Raymond Hettinger rcn.com> writes:
>
>> We should get one written. ISTM, every %-formatting
>> string is directly translatable to an equivalent {}-formatting string.
>>
>
> I've made a start, but I'm not sure how best to handle the '#' and ' '
> conversion flags.
Mine h
On Sat, Oct 3, 2009 at 15:27, Vinay Sajip wrote:
> Brett Cannon python.org> writes:
>
>> Why don't we start something in the sandbox and see how far we can
>> get. If no one beats me to it I will add the directory some time today
>> and we can start hashing out the solution there.
>>
>
> I've don
Brett Cannon python.org> writes:
> No one is saying we should deprecate % any time soon on strings
> themselves or anywhere. This discussion is purely in regards to
> argparse and logging to transition *their* APIs over to {} formatting
> which would most likely involve some deprecation for *usin
Raymond Hettinger rcn.com> writes:
> We should get one written. ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.
>
I've made a start, but I'm not sure how best to handle the '#' and ' '
conversion flags.
Regards,
Vinay Sajip
Nick Coghlan gmail.com> writes:
> I'm starting to think that a converter between the two format
> mini-languages may be the way to go though.
>
> fmt_braces is meant to provide a superset of the capabilites of
> fmt_percent, so a forward converter shouldn't be too hard. A reverse
> converter may
Brett Cannon python.org> writes:
> Why don't we start something in the sandbox and see how far we can
> get. If no one beats me to it I will add the directory some time today
> and we can start hashing out the solution there.
>
I've done a first cut of a converter from %-format to {}-format str
Steven D'Aprano wrote:
On Sun, 4 Oct 2009 04:46:19 am Yuvgoog Greenle wrote:
I just think that if a parser error is causing the SystemExit, I
would rather catch a parser error than catching a SystemExit for the
sake of readability. It saves me the comments:
# Catching SystemExit because parse_
Antoine Pitrou wrote:
MRAB mrabarnett.plus.com> writes:
Another possibility:
A StringFormat class with subclasses PercentStringFormat,
BraceStringFormat, and perhaps DollarStringFormat.
Or:
A StringFormat class with methods parse_percent_format,
parse_brace_format, and parse_dollar_format
* Steven D'Aprano wrote:
> You don't need a comment warning that you are catching SystemExit
> because parse_args raises SystemExit, any more than you need a comment
> saying that you are catching ValueError because some function raises
> ValueError. The fact that you are catching an exception imp
On Sat, Oct 3, 2009 at 8:29 PM, Steven D'Aprano wrote:
> I could show a thousand other examples. It simply isn't true that all,
> or even most, modules have their own exception types.
I might be wrong on this. Your point is extra true for modules in the
standard library (which is what we're talki
On Fri, Oct 2, 2009 at 20:03, Raymond Hettinger wrote:
>
> [Terry Reedy]
>>
>> I would agree, for instance, that an auto-translation tool is needed.
>
> We should get one written. ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.
Why don't we start
On Sat, Oct 3, 2009 at 11:01, Steven D'Aprano wrote:
> On Sun, 4 Oct 2009 01:41:36 am Steven Bethard wrote:
>> 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
On Sun, 4 Oct 2009 04:46:19 am Yuvgoog Greenle wrote:
> I just think that if a parser error is causing the SystemExit, I
> would rather catch a parser error than catching a SystemExit for the
> sake of readability. It saves me the comments:
>
> # Catching SystemExit because parse_args() throws Sys
On Sun, 4 Oct 2009 01:41:36 am Steven Bethard wrote:
> 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 on
MRAB mrabarnett.plus.com> writes:
>
> Another possibility:
>
> A StringFormat class with subclasses PercentStringFormat,
> BraceStringFormat, and perhaps DollarStringFormat.
>
> Or:
>
> A StringFormat class with methods parse_percent_format,
> parse_brace_format, and parse_dollar_format. Ther
Paul Moore gmail.com> writes:
> Still tangential, but it seems to me that this discussion has exposed
> a couple of areas where the logging interface is less than ideal:
>
> - The introspection of the format string to delay computing certain
> items (Eric's suggestion may be an improvement here)
Paul Moore wrote:
2009/10/1 Eric Smith :
It's tangential, but in the str.format case you don't want to check for just
'{asctime}', because you might want '{asctime:%Y-%m-%d}', for example.
But there are ways to delay computing the time until you're sure it's
actually being used in the format
On Sun, 4 Oct 2009 03:38:31 am Yuvgoog Greenle wrote:
> Check it out:
>
> def ParseAndRun():
> crazy_external_function_that_might_exit()
>
> # Argparse blah blah
> parser.parse_args()
>
> if __name__ == "__main__":
> try:
> ParseAndRun()
> except SystemExit:
> #
2009/10/1 Eric Smith :
> It's tangential, but in the str.format case you don't want to check for just
> '{asctime}', because you might want '{asctime:%Y-%m-%d}', for example.
>
> But there are ways to delay computing the time until you're sure it's
> actually being used in the format string, withou
Mark Dickinson wrote:
On Sat, Oct 3, 2009 at 4:41 PM, Steven Bethard wrote:
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.
Definitely useful. Thanks for the summary!
[...]
* Add a parame
Steven Bethard wrote:
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
On Sat, Oct 3, 2009 at 7:21 PM, Michael Foord wrote:
> [snip...]
> Why not just catch SystemExit? If you want a custom exception the overriding
> .exit() should be sufficient.
> I'd be much more interested in Guido's suggestion of auto-generated custom
> help messages for sub-commands.
Check it
On Sat, Oct 3, 2009 at 4:41 PM, Steven Bethard wrote:
> 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.
Definitely useful. Thanks for the summary!
[...]
> * Add a parameter which declares
Yuvgoog Greenle wrote:
On Sat, Oct 3, 2009 at 7:21 PM, Michael Foord wrote:
[snip...]
Why not just catch SystemExit? If you want a custom exception the overriding
.exit() should be sufficient.
I'd be much more interested in Guido's suggestion of auto-generated custom help
messages for sub-
On Oct 3, 2009, at 11:41 AM, Steven Bethard wrote:
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 %-forma
Steven Bethard wrote:
[snip...]
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?
Cool. I didn't realise that help for subcommands was already
> Define "fails":
>
> >>> "{a} {b} c" % {'a':12}
> '{a} {b} c'
>
> That didn't fail...
Ah, my bad. I had completely overlooked that formatting was laxist when
faced with unused named parameters.
Then we need something smarter, like counting the number of unescaped
"%" characters, the number of
On Sat, 3 Oct 2009 at 17:08, Paul Moore wrote:
2009/10/3 Antoine Pitrou :
Steven Bethard gmail.com> writes:
? 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.
2009/10/3 Antoine Pitrou :
> Steven Bethard gmail.com> writes:
>>
>> 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 %-for
Steven Bethard gmail.com> writes:
>
> 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 {}-formatt
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 from SystemExit and that exception
>>> 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
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 from SystemExit and that exception
would be thrown.
ParseError, or something similar.
I suggest this just beca
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 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.
Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > However, while I'd still be a little happier if the .ip attribute
> > went away all together and another means was found to conveniently
> > associate an IPAddress and an IPNetwork, keeping it doesn't bother
> > me anywhere near as much a
Bugbee, Larry schrieb:
>>> Do the users get any say in this?
>>
>> I'm a user! :-)
>>
>> 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)
>
> Ugh! Good point.
>
> Is Python to be an easy-to-lea
46 matches
Mail list logo
