Re: PEP 378: Format Specifier for Thousands Separator

Discussion in 'Python' started by Andrew Berg, May 21, 2013.

  1. Andrew Berg

    Andrew Berg Guest

    On 2013.05.21 14:26, Mark Lawrence wrote:
    > On 21/05/2013 20:13, Skip Montanaro wrote:
    >>> Thank you, but let me rephrase it. I'm already using str.format() but I'd like to use '%' (BINARY_MODULO) operator instead.

    >>
    >> That's unlikely to change. If not deprecated already string
    >> interpolation using the modulo operator has lost favor to the string
    >> object's format method.
    >>

    >
    > Please stop perpetuating this myth, see
    > http://mail.python.org/pipermail/python-dev/2012-February/116789.html
    > and http://bugs.python.org/issue14123
    >

    What myth? People should indeed be using .format(), but no one said % formatting was going away soon. Also, the suggested change to the docs
    wasn't made and the issue is closed. The current docs do not say that % formatting isn't going to be deprecated, but it does mention its
    caveats and suggests .format(). If you are trying to say that % formatting will never ever go away, then you are wrong. It is highly
    unlikely to go away in a 3.x release, but /may/ get phased out in Python 4.0.
    --
    CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
    Andrew Berg, May 21, 2013
    #1
    1. Advertising

  2. On Tue, 21 May 2013 14:53:54 -0500, Andrew Berg wrote:

    > On 2013.05.21 14:26, Mark Lawrence wrote:


    >> Please stop perpetuating this myth, see
    >> http://mail.python.org/pipermail/python-dev/2012-February/116789.html
    >> and http://bugs.python.org/issue14123
    >>

    > What myth?


    The myth that % string formatting is deprecated. It is not deprecated.

    > People should indeed be using .format(),


    If it is useful to them, and not too slow, or indeed if they merely want
    to. And if not, then not.

    This is a good case where the original poster *should* use str.format,
    since it does exactly what he wants, and % does not. Python gives you
    many tools, and the wise man uses the right tool for the job. Sometimes
    that is % and sometimes it is str.format and sometimes it is
    string.Template.

    That str.format looks like Java is irrelevant. Method call syntax is
    common in Python, and is not original to Java. Besides, Python looks like
    many languages: some parts look like Java, some parts look like C, some
    parts remind me of functional languages like Lisp and Haskell, and some
    parts look like Algol or Pascal.


    > but no one said % formatting was going away soon.


    True, but only for the definition "no one = all the people who insist
    that % is deprecated, or soon to be deprecated".


    > Also, the suggested change to the docs
    > wasn't made and the issue is closed. The current docs do not say that %
    > formatting isn't going to be deprecated, but it does mention its caveats
    > and suggests .format(). If you are trying to say that % formatting will
    > never ever go away, then you are wrong. It is highly unlikely to go away
    > in a 3.x release, but /may/ get phased out in Python 4.0.


    What happens in Python 4000 is irrelevant. If somebody is trying to
    "future proof" their code for a version that *may never exist*, and if it
    does exist is likely to be six or eight years away from even starting the
    design phase, they are wasting their time. It is hard enough to track a
    moving target, it is impossible to track a target that isn't even a gleam
    in GvR's eye yet.



    --
    Steven
    Steven D'Aprano, May 22, 2013
    #2
    1. Advertising

  3. Andrew Berg

    Andrew Berg Guest

    On 2013.05.21 21:59, Steven D'Aprano wrote:
    > On Tue, 21 May 2013 14:53:54 -0500, Andrew Berg wrote:
    >
    >> On 2013.05.21 14:26, Mark Lawrence wrote:

    >
    >>> Please stop perpetuating this myth, see
    >>> http://mail.python.org/pipermail/python-dev/2012-February/116789.html
    >>> and http://bugs.python.org/issue14123
    >>>

    >> What myth?

    >
    > The myth that % string formatting is deprecated. It is not deprecated.

    Skip didn't say that it was deprecated.

    >> but no one said % formatting was going away soon.

    >
    > True, but only for the definition "no one = all the people who insist
    > that % is deprecated, or soon to be deprecated".

    Perhaps I missed something, but who is insisting this?

    > What happens in Python 4000 is irrelevant. If somebody is trying to
    > "future proof" their code for a version that *may never exist*, and if it
    > does exist is likely to be six or eight years away from even starting the
    > design phase, they are wasting their time. It is hard enough to track a
    > moving target, it is impossible to track a target that isn't even a gleam
    > in GvR's eye yet.

    I think you misunderstand. I'm not suggesting that format() be used simply because % formatting could be deprecated at some unknown time
    years from now; I was clarifying the status of % formatting.
    --
    CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1
    Andrew Berg, May 22, 2013
    #3
  4. >>>> Please stop perpetuating this myth, see
    >>>> http://mail.python.org/pipermail/python-dev/2012-February/116789.html
    >>>> and http://bugs.python.org/issue14123
    >>>>
    >>> What myth?

    >>
    >> The myth that % string formatting is deprecated. It is not deprecated.

    > Skip didn't say that it was deprecated.


    I didn't mean to create a tempest in a teapot. I was away from
    comp.lang.python, python-bugs, and python-dev for a few years. In
    particular, I didn't ever see the aforementioned thread from Feb 2012.
    Had I known of that thread I would have worded the sentence which
    shall not be repeated differently.

    My apologies...

    Skip
    Skip Montanaro, May 22, 2013
    #4
  5. On Wed, 22 May 2013 05:45:12 -0500, Skip Montanaro wrote:

    > I didn't mean to create a tempest in a teapot. I was away from
    > comp.lang.python, python-bugs, and python-dev for a few years. In
    > particular, I didn't ever see the aforementioned thread from Feb 2012.
    > Had I known of that thread I would have worded the sentence which
    > shall not be repeated differently.
    >
    > My apologies...


    No problem, it's not about you specifically, it's just that some of us
    fans of % formatting can be a tad sensitive about it, especially since
    the idea that it has been deprecated (or soon will be deprecated, or one
    day will be deprecated, and therefore code using it is bad) is relatively
    widespread on the Internet.

    Glad to have you back here!



    --
    Steven
    Steven D'Aprano, May 22, 2013
    #5
  6. On 5/22/2013 10:58 AM, Steven D'Aprano wrote:
    > On Wed, 22 May 2013 05:45:12 -0500, Skip Montanaro wrote:
    >
    >> I didn't mean to create a tempest in a teapot. I was away from
    >> comp.lang.python, python-bugs, and python-dev for a few years. In
    >> particular, I didn't ever see the aforementioned thread from Feb 2012.
    >> Had I known of that thread I would have worded the sentence which
    >> shall not be repeated differently.
    >>
    >> My apologies...

    > No problem, it's not about you specifically, it's just that some of us
    > fans of % formatting can be a tad sensitive about it, especially since
    > the idea that it has been deprecated (or soon will be deprecated, or one
    > day will be deprecated, and therefore code using it is bad) is relatively
    > widespread on the Internet.


    Seems like maybe this should become a question in the Python FAQ.

    --Ned.

    >
    > Glad to have you back here!
    >
    >
    >
    Ned Batchelder, May 22, 2013
    #6
  7. Andrew Berg

    nn Guest

    On May 22, 2:30 pm, Ned Batchelder <> wrote:
    > On 5/22/2013 10:58 AM, Steven D'Aprano wrote:
    >
    > > On Wed, 22 May 2013 05:45:12 -0500, Skip Montanaro wrote:

    >
    > >> I didn't mean to create a tempest in a teapot.  I was away from
    > >> comp.lang.python, python-bugs, and python-dev for a few years.  In
    > >> particular, I didn't ever see the aforementioned thread from Feb 2012.
    > >>   Had I known of that thread I would have worded the sentence which
    > >> shall not be repeated differently.

    >
    > >> My apologies...

    > > No problem, it's not about you specifically, it's just that some of us
    > > fans of % formatting can be a tad sensitive about it, especially since
    > > the idea that it has been deprecated (or soon will be deprecated, or one
    > > day will be deprecated, and therefore code using it is bad) is relatively
    > > widespread on the Internet.

    >
    > Seems like maybe this should become a question in the Python FAQ.
    >
    > --Ned.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > Glad to have you back here!


    Maybe a cformat(formatstring, variables) function should be created
    in the string module so people who prefer that can use it. I don't
    mind the C formatting syntax but I don't like the fact that the %
    operator does something totally different when the first variable is
    an integer and the fact that it misbehaves if the second variable is a
    tuple.
    nn, May 22, 2013
    #7
  8. On 22 May 2013 23:31, Carlos Nepomuceno <> wrote:
    >
    > I still don't understand why % benefits from literals optimization ("'%d'%12345") while '{:d}'.format(12345) doesn't.


    There's no reason why that optimisation can't happen in principle.
    However no one has written a patch for it. Why don't you look into
    what it would take to make it happen?


    Oscar
    Oscar Benjamin, May 23, 2013
    #8
  9. ----------------------------------------
    > From:
    > Date: Thu, 23 May 2013 01:30:53 +0100
    > Subject: Re: PEP 378: Format Specifier for Thousands Separator
    > To:
    > CC: ;
    >
    > On 22 May 2013 23:31, Carlos Nepomuceno <> wrote:
    >>
    >> I still don't understand why % benefits from literals optimization ("'%d'%12345") while '{:d}'.format(12345) doesn't.

    >
    > There's no reason why that optimisation can't happen in principle.
    > However no one has written a patch for it. Why don't you look into
    > what it would take to make it happen?
    >
    >
    > Oscar


    Maybe I'll look into that later, but I couldn't even find how the hell they made _Py_InsertThousandsGrouping() been called.

    That's what I got when analysing % formating:

    Thousands separator format specifier for str.__mod__()
    ======================================================

    @Objects/stringobject.c: implements formatint() for '%' processing
    -Looking for code used in str.format()

    @Objects/stringlib/formatter.h: implements str.format()
    -It uses STRINGLIB_GROUPING() to do the job.

    @Objects/stringlib/stringdefs.h: #define STRINGLIB_GROUPING       _PyString_InsertThousandsGrouping
    @Objects/stringlib/unicodedefs.h: #define STRINGLIB_GROUPING       _PyUnicode_InsertThousandsGrouping
    @Objects/stringobject.c: #define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping
    @Objects/stringobject.h: declares _PyString_InsertThousandsGrouping()
    @???: ??? _PyString_InsertThousandsGrouping ??? _Py_InsertThousandsGrouping
    @Objects/stringlib/localeutil.h: implements _Py_InsertThousandsGrouping()


    Let me explain what that means. I found no relating declarations/definitions that turn _PyString_InsertThousandsGrouping into _Py_InsertThousandsGrouping.

    So, I don't even know how that source code compiles without error.

    :/ really strange...


    Not to mention the lots of code inside header definition files! Weird!!!!
    Carlos Nepomuceno, May 23, 2013
    #9
  10. Andrew Berg

    Jerry Hill Guest

    On Thu, May 23, 2013 at 6:20 PM, Carlos Nepomuceno <
    > wrote:

    > Can str.format() do the following?
    >
    > f = '%d %d %d'
    > v = '1,2,3'
    > print f % eval(v)
    >


    ​Sure:

    Python 3.2.2 (default, Sep 4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)]
    on win32
    >>> f = "{} {} {}"
    >>> v = "1,2,3"
    >>> print(f.format(*eval(v)))

    1 2 3
    >>>


    The * unpacks the tuple returned from eval(), so that you get 3 separate
    parameters passed to format(), instead of the single tuple.​

    --
    ​
    Jerry​
    Jerry Hill, May 24, 2013
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Carlos Nepomuceno
    Replies:
    0
    Views:
    84
    Carlos Nepomuceno
    May 21, 2013
  2. Ned Deily
    Replies:
    0
    Views:
    80
    Ned Deily
    May 21, 2013
  3. Carlos Nepomuceno
    Replies:
    1
    Views:
    93
    88888 Dihedral
    May 24, 2013
  4. Chris “Kwpolska†Warrick

    Re: PEP 378: Format Specifier for Thousands Separator

    Chris “Kwpolska†Warrick, May 21, 2013, in forum: Python
    Replies:
    0
    Views:
    75
    Chris “Kwpolska†Warrick
    May 21, 2013
  5. Skip Montanaro
    Replies:
    0
    Views:
    91
    Skip Montanaro
    May 21, 2013
Loading...

Share This Page