On Sat, Feb 25, 2012 at 2:41 AM, Benjamin Peterson <benjamin@python.org> wrote:

2012/2/24 Tshepang Lekhonkhobe <tshepang@gmail.com>:

...

Hi,

I was of the thought that Old String Formatting |"%s" % foo| was to be phased out by Advanced String Formatting |"{}.format(foo)|. I however keep seeing new code committed into the main VCS using the old style. Is this okay? Is there a policy? I ask also because I expect CPython to lead by example.

Using either is fine I think. It doesn't hurt anyone to have old string formatting around for a long time. In general, +0 for using new string formatting.

Yep. Also, the two can work nicely in tandem as templates for each other that don't need tons of escaping.

...

On another note, will the old format ever be deprecated? Is there a date?

I doubt it.

*If* the old format were ever to be deprecated (and that's a very big if), Python 4k would be the earliest it could happen. More likely the old format will just hang around indefinitely, though. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

It is a burden for some people to learn and remember the exact details of both systems and exactly how they differ. Having both in the stdlib hurts readability for such people. I would prefer that the stdlib only used {} formatting or if not that, that it only used the simple, hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).

If that issue was getting serious, I would prefer if the .format method was deprecated, and only % formatting was kept. I doubt this is as much of an issue as you think, though. Regards, Martin

On Fri, Feb 24, 2012 at 1:52 PM, Tshepang Lekhonkhobe <tshepang@gmail.com> wrote:

On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <martin@v.loewis.de> wrote:

...

...

It is a burden for some people to learn and remember the exact details of both systems and exactly how they differ. Having both in the stdlib hurts readability for such people. I would prefer that the stdlib only used {} formatting or if not that, that it only used the simple, hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).

If that issue was getting serious, I would prefer if the .format method was deprecated, and only % formatting was kept.

Why is that? Isn't .format regarded superior? Or is this just a matter of taste?

It has superior features, but its current implementation is much slower and there is a HUGE body of existing code that would need conversion (a lot of that is automatable), including most uses of the logging module. % formatting is also familiar to anyone who uses C and C++ on a regular basis. as martin said, both will exist for a long time. -gps

On Sat, Feb 25, 2012 at 10:20 AM, <martin@v.loewis.de> wrote:

I find the .format syntax too complicated and difficult to learn. It has so many bells and whistles, making it more than just a *mini* language. So for my own code, I always prefer % formatting for simplicity.

Heh, I've switched almost entirely to .format() just so I never have to worry if: fmt % arg should actually be written as: fmt % (arg,) With fmt.format(arg), the question just never comes up. Since 90%+ of the replacement field specifiers I use are just "{}" or "{!r}" (the format-style equivalents to "%s" and "%r" in printf-style formatting), and most of the rest are either using field references or just {:number_spec} (where the number formatting is the same as that in printf-style) the complexity of the full mini-language doesn't really come into play (although I did find use recently for several of the features in order to emit nicely formatted data from a command line utility). Another *very* handy trick is "{0.attr} {0.attr2}" for concise attribute formatting. Really, what the new-style formatting is most lacking is a tutorial or cookbook style reference to teach people things like: - here's how to do basic string interpolation ("{}") - here's how to use repr() or ascii() instead of str() ("{!r}", "{!a}") - here's how to explicit number your fields so you can refer to the same argument more than once ("{0}") - here's how to name your fields so you can use keyword arguments or format_map() - here's how to access attributes of an object being formatted - here's how to access individual items in a container being formatted - here's how to do implicit string interpolation with format_map() on locals() or vars(obj) - here's how to align (and/or truncate) text within a field - here's how to format numbers - here's how to implicitly invoke strftime And in a more advanced section: - here's how to use __format__() to customise the formatting options for your own class - here's how to use string.StringFormatter to create a custom formatting variant (e.g. one that invokes shlex.quote() on interpolated variables by default) Currently we point them directly at the relevant section of the *language spec*, which is written for people trying to create compliant formatting implementations, not anyone that just wants to *use* the thing. However, while I'm personally a fan of the new format() methods and greatly prefer them to the old way of doing things, I agree it would be a bad idea to try to *force* people to switch if they're used to printf-style formatting and don't have any issues with it (particularly given the current expert-friendly state of the documentation). It's not like printf-style formatting is a security risk or poses some kind of huge maintenance burden. I see it as similar to the getopt/optparse/argparse situation. getopt() has value for consistency with C's getopt() API, argparse is the current recommended best practice, while optparse is kept around because it is so prevalent that it isn't worth trying to remove it. Similarly, printf-style formatting has value for its consistency with C and deserves to be kept around due to both that and its current prevalence. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

I find that strange, especially for an expert Python dev. I, a newbie, find it far friendlier (and easier for a new programmer to grasp). Maybe it's because I use it all the time, and you don't?

That is most likely the case. You learn by practice. For that very reason, the claim "and easier for a new programmer to grasp" is difficult to prove. It was easier for *you*, since you started using it, and then kept using it. I don't recall any particular obstacles learning % formatting (even though I did for C, not for C++). Generalizing that it is *easier* is invalid: you just didn't try learning that instead first, and now you can't go back in a state where either are new to you. C++ is very similar here: they also introduced a new way of output (iostreams, and << overloading). I used that for a couple of years, primarily because people said that printf is "bad" and "not object- oriented". I then recognized that there is nothing wrong with printf per so, and would avoid std::cout in C++ these days, in favor of std::printf (yes, I know that it does have an issue with type safety). So I think we really should fight the impression that % formatting in Python is "bad", "deprecated", or "old-style". Having both may be considered a slight violation of the Zen, however, I would claim that neither formatting API are that obvious - AFAIR, the biggest hurdle in learning printf was to understand the notion of "placeholder", which I think is the reason why people are coming up with so many templating systems (templating isn't "obvious"). Regards, Martin

On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" <martin@v.loewis.de> wrote:

...

I find that strange, especially for an expert Python dev. I, a newbie, find it far friendlier (and easier for a new programmer to grasp). Maybe it's because I use it all the time, and you don't?

That is most likely the case. You learn by practice. For that very reason, the claim "and easier for a new programmer to grasp" is difficult to prove. It was easier for *you*, since you started using it, and then kept using it. I don't recall any particular obstacles learning % formatting (even though I did for C, not for C++). Generalizing that it is *easier* is invalid: you just didn't try learning that instead first, and now you can't go back in a state where either are new to you.

When I started using Python, Advanced format wasn't yet available, so I was forced to use Old style format. It's not a big issue, especially since I had also used C before then. It's just that when Advanced format was introduced, I fell for it, mainly because I found it more readable (also see the sort of power Nick displayed earlier in this thread) not to mention elegant. For that reason, I would recommend any new Python programmer to ignore Old style altogether. That includes those with C background. PS: By newbie, I meant that I'm at the low ranks (at least as compared to you), not that I only started using Python last year. Sorry for the noise.

Big +1 On Feb 26, 2012 4:41 PM, "Eli Bendersky" <eliben@gmail.com> wrote:

On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" <martin@v.loewis.de>wrote:

...

...

I find that strange, especially for an expert Python dev. I, a newbie, find it far friendlier (and easier for a new programmer to grasp). Maybe it's because I use it all the time, and you don't?

That is most likely the case. You learn by practice. For that very reason, the claim "and easier for a new programmer to grasp" is difficult to prove. It was easier for *you*, since you started using it, and then kept using it. I don't recall any particular obstacles learning % formatting (even though I did for C, not for C++). Generalizing that it is *easier* is invalid: you just didn't try learning that instead first, and now you can't go back in a state where either are new to you.

C++ is very similar here: they also introduced a new way of output (iostreams, and << overloading). I used that for a couple of years, primarily because people said that printf is "bad" and "not object- oriented". I then recognized that there is nothing wrong with printf per so, and would avoid std::cout in C++ these days, in favor of std::printf (yes, I know that it does have an issue with type safety).

Not to mention that the performance of iostreams is pretty bad, to the extent that some projects actively discourage using them in favor of either C-style IO (fgets, printf, etc.) or custom IO implementations. This is marginally off-topic, although it does show that an initial thought of deprecating an existing functionality for new one doesn't always work out in the long run, even for super-popular languages like C++.

Eli

_______________________________________________ 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/anacrolix%40gmail.com

On Feb 24, 2012, at 10:39 PM, Martin v. Löwis wrote:

...

It is a burden for some people to learn and remember the exact details of both systems and exactly how they differ. Having both in the stdlib hurts readability for such people. I would prefer that the stdlib only used {} formatting or if not that, that it only used the simple, hard-to-forget forms of % formatting (%s, %d, %f, without elaboration).

If that issue was getting serious, I would prefer if the .format method was deprecated, and only % formatting was kept.

I doubt this is as much of an issue as you think, though.

I personally prefer .format() these days, but I agree that it will be a long time, if ever, we see one of the styles getting dropped. I don't have much of a problem with the stdlib containing both styles as appropriate and preferred by the maintainer, as long as the module is consistent. Also, modules which provide a format-ish API should accept both styles, such as what logging currently does. (It's nice that logging also accepts PEP 292 $-strings too, don't forget about those. :) -Barry

On Feb 24, 2012 6:26 PM, "Mark Lawrence" <breamoreboy@yahoo.co.uk> wrote:

On 24/02/2012 21:37, "Martin v. Löwis" wrote:

...

...

I was of the thought that Old String Formatting |"%s" % foo| was to be phased out by Advanced String Formatting |"{}.format(foo)|.

This is actually not the case, and never was. Some people would indeed like to see that happen, and others are strongly opposed.

As a consequence, both APIs for formatting will coexist for a long time to come (ten years at least); no deprecation is planned.

Regards, Martin

<quote> Quoting the docs http://docs.python.org/py3k/library/stdtypes.html

4.6.2. Old String Formatting Operations

Note

The formatting operations described here are obsolete and may go away in

future versions of Python. Use the new String Formatting in new code.

</quote>

I think this is daft because all of the code has to be supported for the

ten years that MVL has suggested. I suggest a plan that says something like:-

Until Python 3.5 both methods of string formatting will be supported. In Python 3.6 the the old formating style will be deprecated. In Python 3.7 the old style is dead.

I'm fully aware that it isn't likely to be that easy, I'm simply trying

to spark ideas from the core developers and users who are in a far better situation to judge this situation than I am. -infinity. We can't do that as outlined earlier in the thread.

On Sat, Feb 25, 2012 at 05:10, Ned Batchelder <ned@nedbatchelder.com> wrote:

 Has Python *ever* removed a feature except in X.0 releases?

I thought this happens all the time, but with deprecations first. Is that not the case?

On Sat, Feb 25, 2012 at 10:23 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

<quote> Quoting the docs http://docs.python.org/py3k/library/stdtypes.html

4.6.2. Old String Formatting Operations

Note

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

</quote>

I think this is daft because all of the code has to be supported for the ten years that MVL has suggested.

Indeed, that note was written before we decided that getting rid of "%" formatting altogether would be a bad idea. It would be better to update it to say something like: "The formatting operations described here are modelled on C's printf() syntax. They only support formatting of certain builtin types, and the use of a binary operator means that care may be needed in order to format tuples and dictionaries correctly. As the new string formatting syntax is more powerful, flexible, extensible and handles tuples and dictionaries naturally, it is recommended for new code. However, there are no current plans to deprecate printf-style formatting." Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 25/02/2012 13:13, Mark Lawrence wrote:

On 25/02/2012 05:55, Nick Coghlan wrote:

...

On Sat, Feb 25, 2012 at 10:23 AM, Mark Lawrence<breamoreboy@yahoo.co.uk> wrote:

...

<quote> Quoting the docs http://docs.python.org/py3k/library/stdtypes.html

4.6.2. Old String Formatting Operations

Note

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

</quote>

I think this is daft because all of the code has to be supported for the ten years that MVL has suggested.

Indeed, that note was written before we decided that getting rid of "%" formatting altogether would be a bad idea.

It would be better to update it to say something like:

"The formatting operations described here are modelled on C's printf() syntax. They only support formatting of certain builtin types, and the use of a binary operator means that care may be needed in order to format tuples and dictionaries correctly. As the new string formatting syntax is more powerful, flexible, extensible and handles tuples and dictionaries naturally, it is recommended for new code. However, there are no current plans to deprecate printf-style formatting."

Cheers, Nick.

That's fine by me, it'll save me changing my own code. I'll put this on the issue tracker if you want, but after the pressing needs of the bar and 6 Nations rugby :)

I would raise this on the issue tracker but it won't let me login. Guess I'm not wanted. :( -- Cheers. Mark Lawrence.

Indeed, that note was written before we decided that getting rid of "%" formatting altogether would be a bad idea.

It would be better to update it to say something like:

"The formatting operations described here are modelled on C's printf() syntax. They only support formatting of certain builtin types, and the use of a binary operator means that care may be needed in order to format tuples and dictionaries correctly. As the new string formatting syntax is more powerful, flexible, extensible and handles tuples and dictionaries naturally, it is recommended for new code. However, there are no current plans to deprecate printf-style formatting."

+1 on rephrasing that doc section, but I wouldn't mention deprecation at all. It's alright to keep calling % formatting "old style" and encouraging .format instead, of course. Eli