Status regarding Old vs. Advanced String Formating
Locked
12
12
Status regarding Old vs. Advanced String Formating
 
|
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. On another note, will the old format ever be deprecated? Is there a date? _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
2012/2/24 Tshepang Lekhonkhobe <[hidden email]>:
> 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. > > On another note, will the old format ever be deprecated? Is there a date? I doubt it. -- Regards, Benjamin _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Tshepang Lekhonkhobe
Tshepang Lekhonkhobe wrote:
> 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. > > On another note, will the old format ever be deprecated? Is there a date? Brett Cannon wrote: > On Tue, Feb 22, 2011 at 10:43, Ethan Furman wrote: > >> Greetings! >> >> According to these release notes in Python 3.0, %-formatting will be >> going away. >> >> http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting >> >> However, I was unable to find any further evidence of actual >> deprecation in 3.1 or 3.2... does anybody know the status of this? >> > > There isn't one. =) > > The very long term view is for %-formatting to go away, but that's as > far as the thinking has gone. There are currently no plans to > introduce any deprecation warning, and I highly doubt we will even > remove the feature in Python 3, giving you probably at least another > decade of use at our current major version release schedule. =) _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Benjamin Peterson-3
On Sat, Feb 25, 2012 at 2:41 AM, Benjamin Peterson <[hidden email]> wrote:
> 2012/2/24 Tshepang Lekhonkhobe <[hidden email]>: >> 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 | [hidden email] | Brisbane, Australia _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Benjamin Peterson-3
On 2/24/2012 11:41 AM, Benjamin Peterson wrote:
> 2012/2/24 Tshepang Lekhonkhobe<[hidden email]>: >> 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. 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). -- Terry Jan Reedy _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Tshepang Lekhonkhobe
> 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 _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Terry Reedy
> 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 _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <[hidden email]> 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? _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
On Fri, Feb 24, 2012 at 1:52 PM, Tshepang Lekhonkhobe
<[hidden email]> wrote: > On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <[hidden email]> 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 _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by "Martin v. Löwis"
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 _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Tshepang Lekhonkhobe
Zitat von Tshepang Lekhonkhobe <[hidden email]>: > On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <[hidden email]> 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? 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. Regards, Martin _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by "Martin v. Löwis"
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. -- Cheers. Mark Lawrence. _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
-infinity. We can't do that as outlined earlier in the thread. _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Mark Lawrence
On 2/24/2012 7:23 PM, Mark Lawrence wrote:
> 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. formatting. Python does a great job keeping things working into the future, and there are so many features in the language and library that are there to keep old code working in spite of newer ways to accomplish the same task. Has Python *ever* removed a feature except in X.0 releases? Why are we even discussing this? Two ways to format strings is no big deal, especially considering how heavily used these tools are. And btw, if you include the almost-never-mentioned string.Template, there are at least three ways to do it, maybe more. --Ned. _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Mark Lawrence
On Sat, Feb 25, 2012 at 10:23 AM, Mark Lawrence <[hidden email]> 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 | [hidden email] | Brisbane, Australia _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by "Martin v. Löwis"
On Sat, Feb 25, 2012 at 10:20 AM, <[hidden email]> 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 | [hidden email] | Brisbane, Australia _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Ned Batchelder
On Sat, Feb 25, 2012 at 05:10, Ned Batchelder <[hidden email]> 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? _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by "Martin v. Löwis"
On Sat, Feb 25, 2012 at 02:20, <[hidden email]> wrote:
> Zitat von Tshepang Lekhonkhobe <[hidden email]>: >> On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <[hidden email]> >>> 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? > > 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. 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? _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Tshepang Lekhonkhobe
Tshepang Lekhonkhobe wrote:
> On Sat, Feb 25, 2012 at 05:10, Ned Batchelder <[hidden email]> 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? Hardly "all the time". Only when absolutely necessary, the exception being the 2.x -> 3.x transition which was designed to break backwards compatibility for the sake of "cleaning up" the language. And even there, the changes were very conservative. If there is every going to be a similar 3.x -> 4.x transition, and there may not be, it will probably be 10 years away. Python is a lot more mature now, and consequently the costs of breaking backwards compatibility is much greater, particularly when it comes to language features like % rather than modules. After all, it is easy for Python users to take a copy of a depreciated module and keep using it, but it's very difficult for them to fork Python if a language feature is removed. -- Steven _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: Status regarding Old vs. Advanced String Formating
|
|
In reply to this post by Tshepang Lekhonkhobe
> 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 _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
«
Return to Python - python-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |