Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

Status regarding Old vs. Advanced String Formating

 

 

First page Previous page 1 2 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded


tshepang at gmail

Feb 24, 2012, 8:24 AM

Post #1 of 29 (1840 views)
Permalink
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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


benjamin at python

Feb 24, 2012, 8:41 AM

Post #2 of 29 (1821 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

2012/2/24 Tshepang Lekhonkhobe <tshepang [at] gmail>:
> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ethan at stoneleaf

Feb 24, 2012, 9:00 AM

Post #3 of 29 (1822 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Feb 24, 2012, 9:09 AM

Post #4 of 29 (1821 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Sat, Feb 25, 2012 at 2:41 AM, Benjamin Peterson <benjamin [at] python> wrote:
> 2012/2/24 Tshepang Lekhonkhobe <tshepang [at] gmail>:
>> 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 [at] gmail   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tjreedy at udel

Feb 24, 2012, 11:52 AM

Post #5 of 29 (1813 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On 2/24/2012 11:41 AM, Benjamin Peterson wrote:
> 2012/2/24 Tshepang Lekhonkhobe<tshepang [at] gmail>:
>> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

Feb 24, 2012, 1:37 PM

Post #6 of 29 (1814 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

Feb 24, 2012, 1:39 PM

Post #7 of 29 (1814 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tshepang at gmail

Feb 24, 2012, 1:52 PM

Post #8 of 29 (1813 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <martin [at] v> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


greg at krypto

Feb 24, 2012, 1:56 PM

Post #9 of 29 (1815 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Fri, Feb 24, 2012 at 1:52 PM, Tshepang Lekhonkhobe
<tshepang [at] gmail> wrote:
> On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <martin [at] v> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

Feb 24, 2012, 2:02 PM

Post #10 of 29 (1819 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

Feb 24, 2012, 4:20 PM

Post #11 of 29 (1808 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

Zitat von Tshepang Lekhonkhobe <tshepang [at] gmail>:

> On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <martin [at] v> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


breamoreboy at yahoo

Feb 24, 2012, 4:23 PM

Post #12 of 29 (1819 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


brian at python

Feb 24, 2012, 6:05 PM

Post #13 of 29 (1818 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Feb 24, 2012 6:26 PM, "Mark Lawrence" <breamoreboy [at] yahoo> 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.


ned at nedbatchelder

Feb 24, 2012, 7:10 PM

Post #14 of 29 (1805 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

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.
I don't understand why we'd even consider getting rid of old-style
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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Feb 24, 2012, 9:55 PM

Post #15 of 29 (1816 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Sat, Feb 25, 2012 at 10:23 AM, Mark Lawrence <breamoreboy [at] yahoo> 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 [at] gmail   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Feb 24, 2012, 10:21 PM

Post #16 of 29 (1806 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Sat, Feb 25, 2012 at 10:20 AM, <martin [at] v> 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 [at] gmail   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tshepang at gmail

Feb 25, 2012, 12:02 AM

Post #17 of 29 (1808 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Sat, Feb 25, 2012 at 05:10, Ned Batchelder <ned [at] nedbatchelder> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tshepang at gmail

Feb 25, 2012, 12:06 AM

Post #18 of 29 (1812 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Sat, Feb 25, 2012 at 02:20, <martin [at] v> wrote:
> Zitat von Tshepang Lekhonkhobe <tshepang [at] gmail>:
>> On Fri, Feb 24, 2012 at 23:39, "Martin v. Löwis" <martin [at] v>
>>> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

Feb 25, 2012, 1:41 AM

Post #19 of 29 (1801 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

Tshepang Lekhonkhobe wrote:
> On Sat, Feb 25, 2012 at 05:10, Ned Batchelder <ned [at] nedbatchelder> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

Feb 25, 2012, 2:20 AM

Post #20 of 29 (1805 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

> 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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


songofacandy at gmail

Feb 25, 2012, 2:44 AM

Post #21 of 29 (1801 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

I don't feel "similar to other language" is not enough reason for
builtins violates the Zen.

Violating the Zen by standard library like `getopt` for compatibility to
other language or API is good.
So, I prefer moving %-style format from builtin str to function in string
module in Python 4.

On Sat, Feb 25, 2012 at 7:20 PM, "Martin v. Löwis" <martin [at] v> 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).
>
> 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
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com



--
INADA Naoki  <songofacandy [at] gmail>
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tshepang at gmail

Feb 25, 2012, 2:46 AM

Post #22 of 29 (1801 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On Sat, Feb 25, 2012 at 12:20, "Martin v. Löwis" <martin [at] v> 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.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


breamoreboy at yahoo

Feb 25, 2012, 5:13 AM

Post #23 of 29 (1796 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On 25/02/2012 05:55, Nick Coghlan wrote:
> On Sat, Feb 25, 2012 at 10:23 AM, Mark Lawrence<breamoreboy [at] yahoo> 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 :)

--
Cheers.

Mark Lawrence.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


breamoreboy at yahoo

Feb 25, 2012, 12:16 PM

Post #24 of 29 (1797 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

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 [at] yahoo> 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.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


breamoreboy at yahoo

Feb 25, 2012, 12:49 PM

Post #25 of 29 (1790 views)
Permalink
Re: Status regarding Old vs. Advanced String Formating [In reply to]

On 25/02/2012 20:16, Mark Lawrence wrote:
> 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 [at] yahoo> 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. :(
>

But there's more than one way of skinning a cat.
http://bugs.python.org/issue14123

--
Cheers.

Mark Lawrence.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

First page Previous page 1 2 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.