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

[Georg Brandl]

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-learn-and-remember language?  I submit we are
> losing that one.  To a user, this will be confusing.  To a C programmer
> coming over to Python, especially so.  Some of what makes %-formatting easy
> to remember is its parallel in C.

To a .NET programmer coming to Python (think IronPython), %-formatting will
be strange, while {}-style formatting will be familiar.  I don't know how many
programmers come to Python from C nowadays.

I also think that we are merely so accustomed to ``"..." % bar`` that we never
think about new users who go "Huh? String modulo string?" -- why should that
initial discomfort be less than that of calling a method on a literal?

Being able to call a method on literals is simply consistent; literals are
objects as well as an object referred to by a name.  There are languages where
you can't even call ``foo[bar].baz()`` because method calls only work on single
names.  I call that ugly.

> I'm conflicted.  Philosophically I like the idea of mnemonic names over
> positional variables and allowing variable values determined elsewhere to be
> inserted in print strings.  It is appealing.
> 
> Unless the benefit is at least 2x, a change should not be made,

I don't see how numbers like "2x" can be applied when measuring the
benefit of a language feature.

> and I don't
> think this benefit rises to where it is worth the confusion and problems.
> ...and converting the legacy base.  And forget pretty, not that %-formatting
> is pretty either.  Besides, according to the bench, it is slower too.  And it
> will take editors a while before the new syntax is supported and colorized,
> thus some errors for a while.

This is no different from all other language features.  Some editors I
encountered do not yet color the with statement.  Should I therefore refrain
from using it?

Highlighting formatting placeholders in string literals is questionable anyway,
since a highlighter has no way of knowing whether a given string literal will
be used for formatting.

> and if one wants a "{" or a "}" in the printed output, one has to escape
> it?  That is -2x over wanting a "%" in the output.

Again a number.  Where does it come from?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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 3144 review.

[Nick Coghlan]

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 as having network equivalence defined in
>  > terms of something other than the network ID and the netmask.
> 
> s/equivalence/equality/
> 
> There are several notions of equivalence in play, and all can be
> implemented as methods.  The question is which one is going to be "==".

I have just enough pure math in my educational background to think of
'equality' as the 'default equivalence class', but yes, the meaning of
"==" is exactly what I was referring to.

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 389: argparse - new command line parsing module

[Yuvgoog Greenle]

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.

On Sat, Oct 3, 2009 at 8:15 AM, Nick Coghlan  wrote:
> Toshio Kuratomi wrote:
>> About exit(), I agree with others about wanting to catch the exception
>> myself and then choosing to exit from the code.  I'm not sure that it's
>> actually useful in practice, though...it might just feel cleaner but not
>> actually be that helpful.
>
> As others have pointed out, if you want to do that then you can just
> catch SystemExit.
>
> 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/ubershmekel%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

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

[Steven Bethard]

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 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

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

[Michael Foord]

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 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
  
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.


Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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

[Steven Bethard]

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

[Steven Bethard]

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 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] summary of transitioning from % to { } formatting

[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 %-formatting first and then {}-formatting if it fails?

This would be a reasonable heuristic. It should be done only on the first call,
though, and then the result remembered (for both performance reasons and
consistency).

The cases where a format string would function in both formatting styles and
expect the same parameters must be very rare in the real world.

Regards

Antoine.


___
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] summary of transitioning from % to {} formatting

[Paul Moore]

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 %-formatting first and then {}-formatting if it fails?
>
> This would be a reasonable heuristic. It should be done only on the first 
> call,
> though, and then the result remembered (for both performance reasons and
> consistency).
>
> The cases where a format string would function in both formatting styles and
> expect the same parameters must be very rare in the real world.

Define "fails":

>>> "{a} {b} c" % {'a':12}
'{a} {b} c'

That didn't fail...

Paul.
___
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] summary of transitioning from % to {} formatting

[R. David Murray]

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. should the method
? just try %-formatting first and then {}-formatting if it fails?


This would be a reasonable heuristic. It should be done only on the first call,
though, and then the result remembered (for both performance reasons and
consistency).

The cases where a format string would function in both formatting styles and
expect the same parameters must be very rare in the real world.


Define "fails":


"{a} {b} c" % {'a':12}

'{a} {b} c'

That didn't fail...


Also, what if both fail?  Which failure's error message gets printed?

--David (RDM)___
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] summary of transitioning from % to {} formatting

[Antoine Pitrou]

> 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 pairs of braces, and try first the
formatting style expecting the greatest number of parameters. It can
either be done cheaply in Python, or more rigourously by providing an
extra API to the existing C parsing routines.

This might look fragile, but we should not forget that we are talking
about uses - logging, etc. - which will most of time involve very simple
format strings, such that making an automatic decision is not too
difficult. In the more undecideable cases, the heuristic might decide to
raise an exception and require the developer to specify the formatting
style explicitly (by adding e.g. style='%' or style='{}' to the method
call).

Regards

Antoine.


___
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

[Michael Foord]

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 
implemented. :-)


Michael



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
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] summary of transitioning from % to {} formatting

[Barry Warsaw]

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 %-formatting and not {}-formatting, e.g.
logging.Formatter accepts::
 logging.Formatter(fmt="%(asctime)s - %(name)s")
but not::
 logging.Formatter(fmt="{asctime} - {name}")


I'd like to at least keep in mind $-strings.  I don't have any  
experience with {}-strings w.r.t. i18n translators, but I'm very  
confident that $-strings are better for translators than %-strings.   
OT1H {}-strings don't suffer from the #1 problem of %-strings: leaving  
off the trailing 's' or whatever.  OTOH, I suspect that $-strings are  
still easier for the simple substitution case; for example, it's  
conceivable that translators may forget the trailing close brace.


Since we're likely to have multiple formatting styles at least for  
Python 3's lifetime, I'd like any solution we come up with to at least  
not preclude the use of $-strings.


I also don't think this is a case of anti-TOOWTDI.  For most  
situations {}-strings are great (IMO), but in the specific translation  
domain, I suspect $-strings are still better.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
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

[Michael Foord]

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-commands.



Check it out:

def ParseAndRun():
crazy_external_function_that_might_exit()

# Argparse blah blah
parser.parse_args()

if __name__ == "__main__":
try:
ParseAndRun()
except SystemExit:
# was it crazy_external_function_that_might_exit or an argparse error?


I know this might come through as bike shedding but it's just
customary python that every module have it's own exception types as to
not mix them up with others.

  


Then subclass and override .exit() as discussed - or put proper 
exception handling around the call to parse_args() (optionally 
rethrowing with whatever custom exception type you wish).


Michael

--yuv
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] summary of transitioning from % to {} formatting

[Mark Dickinson]

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 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.

+1.

> * 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.

Uurgh.  This just feels... icky.  A badly-rationalized -1 from me.

> * 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

+0.5.  Seems like it could work, but the first solution feels
cleaner.

> * 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'm reserving judgement on this one until it becomes clear how
feasible it is.  Without having thought about it too hard, this sounds
potentially tricky and bug-prone.

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 389: argparse - new command line parsing module

[Yuvgoog Greenle]

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 out:

def ParseAndRun():
crazy_external_function_that_might_exit()

# Argparse blah blah
parser.parse_args()

if __name__ == "__main__":
try:
ParseAndRun()
except SystemExit:
# was it crazy_external_function_that_might_exit or an argparse error?


I know this might come through as bike shedding but it's just
customary python that every module have it's own exception types as to
not mix them up with others.

--yuv
___
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] summary of transitioning from % to {} formatting

[MRAB]

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.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


I'm not keen on deprecating strings in favour of callables and then
callables in favour of 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?


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. There could also be a
format-guesser method.


I don't think there is consensus yet on which of these proposals
should be the "blessed" one.



___
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] summary of transitioning from % to {} formatting

[MRAB]

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 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.


+1.

[snip]
'fmt' (which is an abbreviation for 'format') and 'format'? Maybe 'fmt'
and 'style' instead?
___
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

[Paul Moore]

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, without parsing the format string.
> Now that I think of it, the same technique could be used with %-formatting:

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).
- The "call str() on any non-string object to get a format string" API
(which precludes string subclasses).

I suspect other APIs will exist with similar issues once the whole
question of supporting multiple format syntaxes gets wider
publicity...

Paul.
___
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

[Steven D'Aprano]

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:
>         # was it crazy_external_function_that_might_exit or an
> argparse error?

Does it matter? What difference does it make?


> I know this might come through as bike shedding but it's just
> customary python that every module have it's own exception types as
> to not mix them up with others.

You are mistaken.

>>> import os
>>> os.path.split(45)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.6/posixpath.py", line 82, in split
i = p.rfind('/') + 1
AttributeError: 'int' object has no attribute 'rfind'

Plain, ordinary AttributeError, not OSModuleSubclassOfAttributeError.

I could show a thousand other examples. It simply isn't true that all, 
or even most, modules have their own exception types.

There's no reason to treat SystemExit as special in this regard. 
optparse, for example, calls sys.exit(), which operates by raising 
SystemExit. Ordinary SystemExit, not a special module-specific 
subclass.



-- 
Steven D'Aprano
___
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

[Michael Foord]

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 string, without parsing the format string.
Now that I think of it, the same technique could be used with %-formatting:



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).
- The "call str() on any non-string object to get a format string" API
(which precludes string subclasses).
  


Calling str on non-string objects to get a format string does not 
(prima-facie) preclude string subclasses:


>>> class X(str): pass
...
>>> class Y(object):
...  def __str__(self):
...   return X('foo')
...
>>> a = Y()
>>> type(str(a))


Michael


I suspect other APIs will exist with similar issues once the whole
question of supporting multiple format syntaxes gets wider
publicity...

Paul.
___
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/
http://www.voidspace.org.uk/blog


___
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

[Vinay Sajip]

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).

Yes, but that's an implementation detail and not part of the logging interface.
It can be changed without any particular additional impact on user code - when
I say "additional" I mean apart from the need to change the format strings to
{} format, which they would have to do anyway at some point.

> - The "call str() on any non-string object to get a format string" API
> (which precludes string subclasses).

It doesn't preclude string subclasses: it just calls str() on an arbitrary
message object to get the string representation for that object. The return
value is used to interpolate into the formatted output, and that's all. So
I don't understand what's being precluded and how - please elaborate.

Thanks & regards,

Vinay Sajip

___
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] summary of transitioning from % to { } formatting

[Antoine Pitrou]

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. There could also be a
> format-guesser method.

I'm sorry to say this, but I think these suggestions are getting foolish. We
core developers might have an interest in transitioning users from one
formatting style to another, but the users mostly don't care and don't want to
bother. Imposing on users the explicit use of such wrapper classes, moreover
with such awfully long-winded names, is not helpful to them at all, and it will
earn Python the reputation of a language which imposes silly constructs in the
name of purity.

If we can't find a way to make things almost transparent, we should IMO abandon
the whole idea of a transition.

Regards

Antoine.


___
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] summary of transitioning from % to {} formatting

[Steven D'Aprano]

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 only %-formatting and not {}-formatting, e.g.
> logging.Formatter accepts::
>   logging.Formatter(fmt="%(asctime)s - %(name)s")
> but not::
>   logging.Formatter(fmt="{asctime} - {name}")

Why is this a problem? Is it because the APIs require extra 
functionality that only {} formatting can provide? Possibly, but I 
doubt it -- I expect that the reason is:

(1) Some people would like to deprecate % formatting, and they can't 
while the std lib uses % internally.

(2) Some APIs in the std lib are tightly coupled to their internal 
implementation, and so you can't change their implementation without 
changing the API as well.

Remove either of these issues, and the problem becomes a non-problem, 
and no action is needed. Personally, I'd like to see no further talk 
about deprecating % until at least Python 3.2, that is, the *earliest* 
we would need to solve this issue would be 3.3. As the Zen 
says, "Although never is often better than *right* now."


> 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). 

-1 on that. Time will tell if I change my mind in a couple of years, but 
I suspect not -- for simple formatting, I far prefer %. Judging by the 
reaction on comp.lang.python when this has been discussed in the past, 
I think a large (or at least loud) proportion of Python programmers 
agree with me.


> 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.

+0.5


> * Create string subclasses which convert % use to .format calls::
> __ = brace_fmt
> logging.Formatter(fmt=__("{asctime} - {name}"))

There are a few problems with this approach:

- Nobody has yet demonstrated that this brace_fmt class is even 
possible. It should be easy to handle a restricted set of simple 
templates (e.g. of the form "%(name)s" only), but what of the full 
range of behaviour supported by % formatting?

- Even if it is doable, it is a wrapper class, which means the module 
will suffer a performance hit on every call. At this time, we have no 
idea what the magnitude of that hit will be, but .format() is already 
slower than % so it will likely be significant.

- It strikes me as hideously ugly. I for one would delay using it as 
long as possible, no matter how many DepreciationWarnings I got. I'd 
drag my feet and avoid changing and complain loudly and then become 
sullen and resentful when I couldn't avoid making the change. I'd much 
rather go straight from %-based templates to {} in a single step than 
have this Frankenstein monster intermediate.


[...]
> * 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.

+0.5

> * Create translators between %-format and {}-format::
> assert to_braces("%(asctime)s") == "{asctime}"
> assert to_percents("{asctime}") == "%(asctime)s"

+1, assuming such translators are even possible. Being optimistic, such 
translators would have one additional benefit: they would enable 
modules to completely decouple the API they offer from their internal 
implementation, without paying a runtime cost on every call, just a 
single once-off translation at initialisation time.

In theory, this could mean that modules could, if they choose, continue 
to offer an API based on % long after str.__mod__ is removed from the 
language.


-- 
Steven D'Aprano
___
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

[Steven D'Aprano]

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 SystemExit on
> parser errors.

But why are you catching the error? As a general rule, you *want* your 
command line app to exit if it can't understand the arguments you pass 
to it. What else can it do? Guess what you wanted?

Assuming you have a reason for catching the exception, I don't see that 
there's any difference in readability between these:

parser = argparse.ArgumentParser()
setup_args(parser)
try:
ns = parser.parse_args()
except argparse.ParserError:
process_error()
else:
main(ns)

and:

parser = argparse.ArgumentParser()
setup_args(parser)
try:
ns = parser.parse_args()
except SystemExit:
process_error()
else:
main(ns)


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 implies that 
the function might raise that exception. A comment like:

"Catching SystemExit because parse_args() throws SystemExit on parser 
errors."

is up them with comments like this:

x += 1  # Add 1 to x.



-- 
Steven D'Aprano
___
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] summary of transitioning from % to {} formatting

[Brett Cannon]

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 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}")
>
> Why is this a problem? Is it because the APIs require extra
> functionality that only {} formatting can provide? Possibly, but I
> doubt it -- I expect that the reason is:
>
> (1) Some people would like to deprecate % formatting, and they can't
> while the std lib uses % internally.
>
> (2) Some APIs in the std lib are tightly coupled to their internal
> implementation, and so you can't change their implementation without
> changing the API as well.
>
> Remove either of these issues, and the problem becomes a non-problem,
> and no action is needed. Personally, I'd like to see no further talk
> about deprecating % until at least Python 3.2, that is, the *earliest*
> we would need to solve this issue would be 3.3. As the Zen
> says, "Although never is often better than *right* now."

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 *using* %
formatting in those APIs. But % formatting on strings themselves is
not directly being discussed here.

-Brett
___
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

[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 {}-formatting string.

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.

-Brett
___
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

[Yuvgoog Greenle]

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 talking about for argparse).

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 SystemExit on parser errors.

# Subclassing ArgumentParser and overriding exit because I don't want
to exit() upon parser errors.

So I'm sorry if what I said was irrelevant. I've never written or
taken part of writing a std-lib module.

--yuv
___
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

[André Malo]

* 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 implies that
> the function might raise that exception. A comment like:
>
> "Catching SystemExit because parse_args() throws SystemExit on parser
> errors."
>
> is up them with comments like this:
>
> x += 1  # Add 1 to x.

It's semantically different. You usually don't catch SystemExit directly, 
because you want your programs to be stopped. Additionally, a library 
exiting your program is badly designed, as it's unexpected. Thatswhy such a 
comment is useful.

Here's what I'd do: I'd subclass SystemExit in this case and raise the 
subclass from argparse. That way all parties here should be satisifed. (I 
do the same all the time in my signal handlers - that's another reason I'd 
rather not catch SystemExit directly as well :-)

nd
-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
  -- aus einer Rezension


___
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] summary of transitioning from % to {} formatting

[MRAB]

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. There could also be a

 format-guesser method.


I'm sorry to say this, but I think these suggestions are getting 
foolish. We core developers might have an interest in transitioning 
users from one formatting style to another, but the users mostly 
don't care and don't want to bother. Imposing on users the explicit 
use of such wrapper classes, moreover with such awfully long-winded 
names, is not helpful to them at all, and it will earn Python the 
reputation of a language which imposes silly constructs in the name 
of purity.



Fair enough.

The purpose of the post was really just so that we cover as many
possibilities as we can so that if at some time in the future someone
asks why we didn't consider such-and-such then we won't be saying "Oh,
never thought of that!". :-)

If we can't find a way to make things almost transparent, we should 
IMO abandon the whole idea of a transition.




___
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

[Robert Kern]

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_args() throws SystemExit on
parser errors.


But why are you catching the error? As a general rule, you *want* your 
command line app to exit if it can't understand the arguments you pass 
to it. What else can it do? Guess what you wanted?


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. I require a particular IPython 
exception type in order for the error to be recognized correctly in the %magic 
subsystem.


The other use case, as mentioned earlier, was for debugging your parser on the 
interactive prompt. A custom subclass may also be able to hold more 
machine-readable information about the error than the formatted error message, 
but I don't have any particular use cases about what may be the most useful.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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

[Vinay Sajip]

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 strings. I'm not
sure where you want to put it in the sandbox, I've created a gist on GitHub:

http://gist.github.com/200936

Not thoroughly tested, but runs in interactive mode so you can try things out.
All feedback appreciated!

Regards,


Vinay

___
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

[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 have to punt with ValueError when it finds things that
> cannot be expressed in the fmt_percent mini language though.

I've done a first cut of a forward (% -> {}) converter:

http://gist.github.com/200936

but I'm not sure there's a case for a converter in the reverse direction, if
we're encouraging movement in one particular direction.

Regards,

Vinay Sajip



___
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

[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.

Regards,

Vinay Sajip


___
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] summary of transitioning from % to { } formatting

[Vinay Sajip]

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 *using* %
> formatting in those APIs. But % formatting on strings themselves is
> not directly being discussed here.

While I have no problem with supporting {}-formatting in logging if we find a
good way of doing it, one thing that bothers me about transitioning the logging
API to deprecate or otherwise de-emphasise %-formatting is the question of
performance. Now, str.format is more flexible than str.__mod__ and so some
performance loss may be tolerable in many scenarios. However, in the feedback I
regularly get about logging, people are concerned about performance. No-one ever
comes up with any hard numbers, but logging is often bashed as slow (see e.g.
Andrii Mishkovskyi's LoggingPackage page on the Python wiki). I don't especially
want to add fuel to the fire, as any performance degradation caused by
supporting {}-formatting will likely just result in more finger-pointing at
logging in general.

Regards,

Vinay Sajip


___
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

[Brett Cannon]

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 done a first cut of a converter from %-format to {}-format strings. I'm 
> not
> sure where you want to put it in the sandbox, I've created a gist on GitHub:
>
> http://gist.github.com/200936
>
> Not thoroughly tested, but runs in interactive mode so you can try things out.
> All feedback appreciated!

I mentioned it in the README. We now have two separate attempts at
converting from % to {}. If people are serious about this we should
start to work on a single implementation.

-Brett
___
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

[Benjamin Peterson]

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 handles it differently for each type specifier.



-- 
Regards,
Benjamin
___
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] summary of transitioning from % to {} formatting

[Terry Reedy]

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 {}-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 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}")


How about combining these two. Add an optional form or style=xxx 
parameter -- which could also allow DOLLARS for $-formats -- for 
resolving ambiguities. If not present, make a reasonable guess. IE, if 
string has no '%' and multiple {} pairs, or no {} pairs and multiple %s, 
the guess is at least .999 sure. which is to not, not hardly a guess. 
The extra arg can be supplied if and when needed.


The machinery for this should be not be logging specific, so it can be 
used through throughout the library, and exposed so that others can use it.


Terry Jan Reedy

___
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

[MRAB]

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 to {}-format strings. I'm not
sure where you want to put it in the sandbox, I've created a gist on GitHub:

http://gist.github.com/200936

Not thoroughly tested, but runs in interactive mode so you can try things out.
All feedback appreciated!


Interesting that you're using the %-format to translate %-formats to
{}-formats! :-)
___
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

[Vinay Sajip]

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/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] summary of transitioning from % to {} formatting

[MRAB]

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 %-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 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}")


How about combining these two. Add an optional form or style=xxx 
parameter -- which could also allow DOLLARS for $-formats -- for 
resolving ambiguities. If not present, make a reasonable guess. IE, if 
string has no '%' and multiple {} pairs, or no {} pairs and multiple %s, 
the guess is at least .999 sure. which is to not, not hardly a guess. 
The extra arg can be supplied if and when needed.



Maybe if the style is a callable then that's the formatting function?
(Or is that asking for trouble? :-))

In that case the style could default to a function which guesses which
style is being used and then the appropriate function.

The machinery for this should be not be logging specific, so it can be 
used through throughout the library, and exposed so that others can use it.




___
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

[Steven D'Aprano]

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 ValueError. The fact that you are catching an
> > exception implies that the function might raise that exception. A
> > comment like:
> >
> > "Catching SystemExit because parse_args() throws SystemExit on
> > parser errors."
> >
> > is up them with comments like this:
> >
> > x += 1  # Add 1 to x.
>
> It's semantically different. You usually don't catch SystemExit
> directly, because you want your programs to be stopped. 

Exactly -- so why catch it at all? But even if there is a good reason to 
catch it, there's still no reason to subclass SystemExit unless 
argparse wants to distinguish different types of fatal error, and allow 
code to catch some but not all. But frankly, if I'm having a hard time 
thinking of a reason to catch SystemExit, I'm having an even harder 
time thinking why you'd want to (say) catch SystemExitTooManyArguments 
but not SystemExitMissingArgument.


> Additionally, 
> a library exiting your program is badly designed, as it's unexpected.

It's not unexpected for an argument parser. Do you know any applications 
that run when given invalid arguments? As a general rule, what can the 
application do? Guess what you wanted?


> Thatswhy such a comment is useful.

The comment doesn't tell you anything that wasn't obvious from the code. 
It is pointless.



> Here's what I'd do: I'd subclass SystemExit in this case and raise
> the subclass from argparse. 

In the following code snippet:

try:
ns = argparse.parse_args()
except SystemExit:
...

is there any confusion between SystemExit raised by parse_args and 
SystemExit raised by other components? *What* other components? If 
SystemExit was raised in that try block, where could it have come from 
other than parse_args?

Do you write comments like these?

try:
value = mydict[key]
except KeyError:
# Catch KeyError raised by dict lookup
...


try:
n = mylist.index(x)
except ValueError:
# Catch ValueError raised by mylist.index
...



Useless comments are worse than no comments, because useless comments 
waste the readers' time and they risk becoming out of sync with the 
code and turning into misleading comments.


> That way all parties here should be satisifed.

No. It wastes the time of the argparse developer, it wastes the time of 
people learning argparse, it wastes the time of people who read the 
code and wonder what's the difference between SystemExit and 
ArgparseSystemExit. (Answer: there is no difference.)



-- 
Steven D'Aprano
___
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

[Steven D'Aprano]

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 SystemExit, which is why it's an 
exception and not an unconditional exit. But they're rare, and not 
difficult to deal with: in your case, having argparse raise a subclass 
of SystemExit won't help you, you would still need to subclass, and in 
other cases, you can just catch SystemExit.


> The other use case, as mentioned earlier, was for debugging your
> parser on the interactive prompt. A custom subclass may also be able
> to hold more machine-readable information about the error than the
> formatted error message, but I don't have any particular use cases
> about what may be the most useful.

Nobody has requested that the exception expose more information. They've 
requested that argparse paint the SystemExit a slightly different shade 
of yellow to the colour it already is -- this is pure bike-shedding.

Subclassing SystemExit just in case someday in the indefinite future 
there comes a need to add extra information to the exception falls foul 
of You Ain't Gonna Need It. Keep it simple -- if, someday, such a need 
becomes apparent, then subclass.



-- 
Steven D'Aprano
___
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] Announcing PEP 3136

[Karen Tracey]

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. When the loop terminates through exhaustion of the list (does this
> include when the list was empty?)
> 3. When the loop didn't exit because of a break statement.
>
> HINTS: The way django does it is opposite the way python does it and there
> may be more than one correct answer.
>
>
Django's template language does not have for/else, it has for/empty:
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty

This construct did come from an external snippet that used 'else' instead of
'empty'.  However when it was moved into Django the 'else' name was
specifically rejected because it did the opposite of what for/else does in
Python.

Karen
___
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

[Benjamin Peterson]

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 {}-formatting string.
>
> 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 already started a converter. It's here:
https://code.launchpad.net/~gutworth/+junk/mod2format



-- 
Regards,
Benjamin
___
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

[Nick Coghlan]

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 of extensibility) and error-prone syntax (handling of dicts and
tuples, forgetting trailing type codes in namespace formatting, operator
precedence issues) are what led directly to PEP 3101 and the
introduction of brace formatting.

For the basic cases that percent formatting actually covers, it does a
reasonable job and is often more concise and currently executes faster
than the brace formatted equivalent (this was especially the case before
support for implicit positional argument numbering was added to brace
formatting).

The advantages of brace formatting don't really start to show up until
you actually start using the *new* features that the approach provides,
such as formatting for non-builtin types (e.g. Decimal and datetime
objects), referring to argument subscripts and attributes in field
definitions and the optional explicit numbering of references to
positional arguments (allowing the order of interpolation to be changed
in the format string without having to change the argument order in all
uses of that format string).

Also, don't forget that the percent formatting code has been around for
more than a decade and a half and has been optimised over that time. The
brace formatting code, on the other hand, is relatively new and probably
still offers plenty of opportunities for optimisation (although the
additionally flexibility in the brace formatting approach means that it
is unlikely to ever catch up completely to the raw speed of percent
formatting).

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