string formatting

Discussion in 'Python' started by Jabba Laci, May 6, 2011.

  1. Jabba Laci

    Jabba Laci Guest

    Hi,

    Which is the preferred way of string formatting?

    (1) "the %s is %s" % ('sky', 'blue')

    (2) "the {0} is {1}".format('sky', 'blue')

    (3) "the {} is {}".format('sky', 'blue')

    As I know (1) is old style. (2) and (3) are new but (3) is only
    supported from Python 2.7+.

    Which one should be used?

    Laszlo
     
    Jabba Laci, May 6, 2011
    #1
    1. Advertisements

  2. Jabba Laci

    Web Dreamer Guest

    Jabba Laci a écrit ce vendredi 6 mai 2011 09:18 dans
    According to python's documentation, (3) and (2) are preferred and (1) is
    deprecated.
    HOWEVER, it depends on the target on which your code is going to run.
    i.e. there are plenty of Web servers running python 2.5 (RedHat 5 or 4
    servers i.e., even MacOS OSX 10.5 servers) for which you may be asked to
    develop an application.
    So if you develop, let's say a django or pylons web application for a
    customer who already has his own servers, you have more chances to get it
    running on most servers with (1), only few servers will work with (2) but a
    lot won't with (3) (very few 'enterprise server distros' ship with python
    2.7 "yet"). You can't always "impose" a distribution or python version to
    someone who already has his own servers in production.

    If you develop a distro specific application, then start using (2) or (3) if
    the python version supports it.
    If it's for a portable web application using a framework, use (1) to
    guarantee it will work with older servers which are running a still
    supported distribution. And you will then start using (2) when all server
    OSes shipped with python 2.5 will have reached end of support, and start
    using (3) only when all server OSes shipped with python 2.6 will have
    reached end of support.

    So it really depends on the target it's supposed to run, and depends also
    whether you will have control or not on the target OS and python version.
     
    Web Dreamer, May 6, 2011
    #2
    1. Advertisements

  3. I think you are wrong, % formatting is not deprecated. Do you have a link
    showing otherwise?


    [[email protected] ~]$ python3.2
    Python 3.2a1 (r32a1:83318, Aug 12 2010, 02:17:22)
    [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.'42'


    I see no DeprecationWarning.
     
    Steven D'Aprano, May 6, 2011
    #3
  4. Jabba Laci

    Chris Rebert Guest

    I'm not them, but:
    "Note: The formatting operations described here [involving %] are
    obsolete and may go away in future versions of Python. Use the new
    String Formatting [i.e. format()] in new code."
    http://docs.python.org/dev/library/stdtypes.html#old-string-formatting-operations

    Technically, not formally deprecated, but such a characterization
    isn't too far off the mark either.

    Cheers,
    Chris
     
    Chris Rebert, May 6, 2011
    #4
  5. Jabba Laci

    Web Dreamer Guest

    Chris Rebert a écrit ce vendredi 6 mai 2011 11:23 dans
    Thanks Chris for the link.

    Indeed, They mention:

    "The formatting operations described here are obsolete and may go away in
    future versions of Python. Use the new String Formatting in new code."

    So the proper word is "obsolete" and in my mind I remembered "deprecated"
    since they say it could be removed from future versions of python.

    So I should have said "obsolete".

    What I would like to know is the difference between "deprecated" and
    "obsolete"...
     
    Web Dreamer, May 6, 2011
    #5
  6. Jabba Laci

    nn Guest

    In this context I think obsolete means: Will be removed in some
    undetermined version in the future; 3 versions or more from now.
    There is also pending deprecation: Will be (usually) removed in the
    version after the next. And
    deprecated: Will be removed in the next version.
     
    nn, May 6, 2011
    #6
  7. Not deprecated at all. In context, deprecation *is* a formal process.

    In any case, on occasions that the issue has been raised, there has been
    considerable community objection to removal of % formatting. Guido might
    want to remove it, but I wouldn't bet on it happening before Python 4000.

    It's perfectly safe to continue using % formatting, if you choose.
     
    Steven D'Aprano, May 6, 2011
    #7

  8. Writing x*x instead of x**2 is obsolete, but it will never go away.

    Writing apply(func, args) instead of func(*args) is deprecated. It has
    gone away.

    Obsolete is a value judgment you are welcome to ignore. Deprecation is a
    formal process that warns you that your code *will* break in the future.
     
    Steven D'Aprano, May 6, 2011
    #8
  9. Jabba Laci

    harrismh777 Guest

    I would hope so, since its the way in most of the books, much of the
    doc and a majority of the code...

    I don't really like the old style, not because there is anything
    wrong with it, because its an obvious carry-over from the cryptic
    formatting style of 'C' printf(), and others. It seems to me that the
    purpose of formatting is to make output clear, and therefore the output
    formatting style itself should be clear and clean.
    On the other hand, among the three styles listed by the OP

    (1) "the %s is %s" % ('sky', 'blue')

    (2) "the {0} is {1}".format('sky', 'blue')

    (3) "the {} is {}".format('sky', 'blue')

    ... they all *feel* good... I mean, they're all clear, clean,
    precise...

    On the other hand, while any 'C' programmer is able to see instantly
    that (1) is a some type of formatting construct, (2) & (3) are clear and
    obvious formatting constructs, even for newbies and esp. for non 'C'
    programmers.

    On the other hand, at this point, it seems that this is personal
    preference issue completely. So, if the book says you can do it, and
    there is no formal deprecation process in the works, feel free to
    express yourself with the style that best suits 'you'.

    On the other hand,..... :)



    kind regards,
    m harris
     
    harrismh777, May 6, 2011
    #9
  10. Jabba Laci

    harrismh777 Guest

    On the other hand, consider this 3.x code snip:

    print("the %s is %d" % ('sky', 'blue'))


    That formatting will throw an exception, because the format
    construct is restricting the format entry to be a number, which 'blue'
    clearly isn't....

    The following print() is better, because *any* time or *most* types
    can be substituted and the 'polymorphism' of Python kicks in allowing
    for that, as so:

    print("the {} is {}".format('sky', 3.4))

    print("the {} is {}".format('sky', 'blue'))


    l=['cloudy', 'today']
    print("the {} is {}".format('sky', l))


    On the other hand,.... :)


    kind regards,
    m harris
     
    harrismh777, May 6, 2011
    #10
  11. Jabba Laci

    Neil Cerutti Guest

    C's printf is a venerable example of the power of notation.
    Notation kicks ass. Another that's well known are regular
    expressions. Python uses this powerful idea again in the struct
    module. Any other places?

    Functions and classes are a general purpose, though verbose, form
    of notation and can be used in place of mini languages when you
    don't want to bother, e.g., C++'s iostreams, and pyparsing's
    grammar declarations.

    Lisp declared that you could implement mini-languages in Lisp,
    rather than just parsing them.

    Python 3's format notation is an improvement for Python, since
    Python doesn't need the type information that's crucial for C and
    particularly scanf, an application of C's mini-language that
    Python doesn't need. Delimiting the escape sequences also makes
    it easier to read and parse complex formating declarations.

    For simple constructs there's not much difference between them,
    but if you switch to .format you'll probably reap some benefit.
     
    Neil Cerutti, May 6, 2011
    #11
  12. Jabba Laci

    Ian Kelly Guest

    If you used %d, then that exception is presumably what you wanted. If
    not, then you should just do:

    print("the %s is %s" % ('sky', 'blue'))
    '%s' has exactly the same degree of polymorphism as '{}', because both
    simply call str() on their argument. There are good reasons to use
    format instead of % if possible, but polymorphism isn't one of them.
     
    Ian Kelly, May 6, 2011
    #12
  13. Jabba Laci

    Terry Reedy Guest

    There is in that it special cases tuples. For instance, a message
    function like

    def emsg(x):
    print("The following object caused a proplem: %s" % x)

    raises "TypeError: not all arguments converted during string formatting"
    if x is a tuple with other than 1 member and extracts x[0] if there is
    just one. Neither is the desired behavior. That has been a problem (and
    sometimes a debugging puzzle) in real code One has to remember to write
    something like

    def emsg(x):
    if isinstance(x,tuple):
    x = (x,)
    print(The following object caused a proplem: %s" % x)

    Guido sees that his original design is a bit of a bug trap, which is one
    reason he wanted to replace it.
     
    Terry Reedy, May 6, 2011
    #13
  14. Couldn't you just do that unconditionally?
    print(The following object caused a proplem: %s" % (x,))

    Chris Angelico
     
    Chris Angelico, May 7, 2011
    #14
  15. Er, yes. That's clearly deliberate, because the target uses %d rather
    than %s. If the author wanted to accept anything, she would used %r or %s.

    You might as well argue that:

    print("the {} is {}".format('sky', int(x)))

    is wrong, because if you leave the int out, any object can be used.




    This is not comparing apples with apples. The format equivalent is:

    print("the {} is {:d}".format('sky', 'blue'))

    which will also raise an exception, ValueError instead of TypeError.
     
    Steven D'Aprano, May 7, 2011
    #15
  16. Jabba Laci

    Terry Reedy Guest

    I guess so, as long as one remembers the ','. That does not obviate the
    fact that % x is an attractive nuisance which works until it does not.
     
    Terry Reedy, May 7, 2011
    #16
  17. Jabba Laci

    alex23 Guest

    The same benefit one might get from using the idiomatic 'if not
    list:'?

    ;)
     
    alex23, May 9, 2011
    #17
  18. Jabba Laci

    Web Dreamer Guest

    Web Dreamer a écrit ce vendredi 6 mai 2011 14:10 dans
    Thanks both to Steven and nn for your explanations.

    I was unsure of the difference between deprecated and obsolete.

    So now, if I understand well, obsolete comes before deprecated, such that if
    a feature is obsolete it will be deprecated in an unknown future, after
    which it will be removed once it has been deprecated (a certain time after
    it was rendered obsolete)?
    (might need an aspirin to read that one :) )

    So If I'm right, old string formatting "could" one day be deprecated but it
    is not yet?
     
    Web Dreamer, May 10, 2011
    #18
  19. I wouldn't say that obsolete features "will be" deprecated. That
    expression makes little sense (I know, for I have seen it in eBay's
    API documentation, and it did not fill me with joy). Deprecation is
    (usually) a formal procedure that clearly states that a feature should
    not be used. It may be accompanied by a strict cutoff ("will be
    removed in version X"), or just left vague, but linting tools can
    identify all use of deprecated features.

    Obsolete, however, is simply a description. Sopwith Camels were
    obsolete in the second world war, and VHS has been obsoleted by
    optical disc media. However, if you wish to fly a Camel or play a VHS,
    nothing's stopping you. The sky will still accept your Camel, and your
    VHS player will still talk to your television. (The analogy breaks
    down a bit in that your obsolete VHS player may be using a deprecated
    cabling style, but it's coax that's deprecated, not VHS.) There's no
    "projected end date" for them.

    Generally, a feature is obsolete before it's deprecated, but
    technically that's not a requirement, and API designers can sometimes
    be quite arbitrary. On the other hand, obsolescence is quite informal,
    and people can disagree about whether or not something is. (Hi Ken,
    your continued use of inches is noted. Thank you.)

    Chris Angelico
     
    Chris Angelico, May 10, 2011
    #19
  20. Which is the preferred way of string formatting?

    Sometimes, I use both ;-)
    That can save you from ugly escapes such as %%s or {{0}}.

    Here's an example from the standard library:
    http://hg.python.org/cpython/file/7254c03b7180/Lib/collections.py#l235

    Note the template has both {typename} formatting for the first pass
    and %r style formatting in the generated code.

    Raymond
     
    Raymond Hettinger, May 10, 2011
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.