+1
On 6/6/08, Steve Holden <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>> Greg Ewing wrote:
>>> Nick Coghlan wrote:
>>>
- remove support for passing a single value to a format string
without wrapping it in an iterable first
>>>
>>> But won't that clobber a large number of the simple
Nick Coghlan wrote:
Greg Ewing wrote:
Nick Coghlan wrote:
- remove support for passing a single value to a format string
without wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
Note the part of the propo
On 06/06/2008, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Greg Ewing schrieb:
> > Paul Moore wrote:
> >
> >
> > > Because the second breaks if value is a tuple:
> > >
> >
> > However, changing it now is going to break a huge
> > amount of existing code that uses %-formatting,
> > and in ways that 2t
Greg Ewing schrieb:
Paul Moore wrote:
Because the second breaks if value is a tuple:
However, changing it now is going to break a huge
amount of existing code that uses %-formatting,
and in ways that 2to3 can't reliably fix.
Keeping %-formatting but breaking a large
proportion of its uses do
Greg Ewing schrieb:
Nick Coghlan wrote:
Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
"{num} occurs {num} times in this format string".format(dict(num=2))
If named arguments were to become mandatory, I'd want
to
Nick Coghlan wrote:
Maybe we should ditch support for
positional arguments and just accept a single dictionary as the sole
parameter to format().
"{num} occurs {num} times in this format string".format(dict(num=2))
If named arguments were to become mandatory, I'd want
to be able to write tha
Nick Coghlan wrote:
%r is about the worst case for the new syntax relative to the old - two
characters become 5. It's worth looking at what those extra characters
buy us though:
However, those benefits are only realised some of the
time, and it's only in rare cases that they're all
realised at
Paul Moore wrote:
Because the second breaks if value is a tuple:
However, changing it now is going to break a huge
amount of existing code that uses %-formatting,
and in ways that 2to3 can't reliably fix.
Keeping %-formatting but breaking a large
proportion of its uses doesn't seem like a goo
> Agreed. %(something)s is quirky - you are bound to forget the final "s"
> (or whatever other specifier) from time to time.
But that gives a ValueError the first time you try it, no?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Thu, 5 Jun 2008 10:43:20 pm Nick Coghlan wrote:
> I'm really starting to wonder if supporting positional arguments to
> str.format() *at all* is a mistake. Maybe we should ditch support for
> positional arguments and just accept a single dictionary as the sole
> parameter to format().
>
> For d
Nick Coghlan gmail.com> writes:
>
> %r is about the worst case for the new syntax relative to the old - two
> characters become 5.
Well there are other very common "worst cases" - namely %d, %f (and probably
a few less commonly used ones such as %X).
> For dictionary formatting, str.format() i
On Thu, 5 Jun 2008 08:50:32 pm Paul Moore wrote:
> On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> > Yes, I don't particularly see the advantage of writing:
> >
> > "spam %s spam" % (value,)
> >
> > over
> >
> > "spam %s spam" % value
> >
> > Why require the first version?
>
> Because t
Raymond Hettinger wrote:
From: "Antoine" <[EMAIL PROTECTED]
For me the problem is not about ditching the % operator for an
intuitively-named method like format(). It's the format syntax which has
become much more complicated and error-prone without any clear advantage.
It's seems that way to
Nick Coghlan wrote:
Greg Ewing wrote:
Nick Coghlan wrote:
- remove support for passing a single value to a format string
without wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
Note the part of the propo
Greg Ewing wrote:
Nick Coghlan wrote:
- remove support for passing a single value to a format string without
wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
Note the part of the proposal that allows *any*
On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> Yes, I don't particularly see the advantage of writing:
>
> "spam %s spam" % (value,)
>
> over
>
> "spam %s spam" % value
>
> Why require the first version?
Because the second breaks if value is a tuple:
Python 2.5 (r25:51908, Sep 19 200
On Thu, 5 Jun 2008 11:48:07 am Greg Ewing wrote:
> Nick Coghlan wrote:
> > - remove support for passing a single value to a format string
> > without wrapping it in an iterable first
>
> But won't that clobber a large number of the simple
> use cases that you want to keep %-formatting for?
Yes, I
Nick Coghlan wrote:
- remove support for passing a single value to a format string without
wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
--
Greg
___
Python-Dev
Please, please, please: Keep the % formatting!
In 99% of the Python code I have seen,
the str.format wouldn't gain any advantage
(not even regarding the code readability).
Yes, there may be special cases where str.format
offers more flexibility, but until now I never missed
anything in the % for
From: "Antoine" <[EMAIL PROTECTED]
For me the problem is not about ditching the % operator for an
intuitively-named method like format(). It's the format syntax which has
become much more complicated and error-prone without any clear advantage.
It's seems that way to me too. But, it may be on
> Antoine Pitrou wrote:
>>
>> Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
>> (if I got the format spec right).
>
> repr(s) is even simpler :)
Yes, of course, but in the non-trivial case, e.g. "value=%r" % my_value,
it's much easier to use %-style formatting than playin
On Wed, 4 Jun 2008 11:28:40 pm Nick Coghlan wrote:
> > Not to mention that e.g. "%r" % s is much simpler than
> > "{0!r}".format(s) (if I got the format spec right).
>
> repr(s) is even simpler :)
Fair enough, and I see your smiley, but consider:
"X %r X" % s
"X {0!r} X".format(s)
"X " + repr(
Antoine Pitrou wrote:
Michael Foord voidspace.org.uk> writes:
Simple string formatting with %s and a single object or a tuple meets
>90% of my string formatting needs.
Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
(if I got the format spec right).
repr(s) is even
2008/6/4 Antoine Pitrou <[EMAIL PROTECTED]>:
> Michael Foord voidspace.org.uk> writes:
>> Simple string formatting with %s and a single object or a tuple meets
>> >90% of my string formatting needs.
>
> Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
> (if I got the forma
Michael Foord voidspace.org.uk> writes:
> Simple string formatting with %s and a single object or a tuple meets
> >90% of my string formatting needs.
Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
(if I got the format spec right).
cheers
Antoine.
__
Nick Coghlan wrote:
Martin v. Löwis wrote:
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the year
when I retire, i.e. 2037).
Now this is news to me -- was there a discussion that changed the
lifetime expectancy of
Martin v. Löwis wrote:
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the year
when I retire, i.e. 2037).
Now this is news to me -- was there a discussion that changed the
lifetime expectancy of str.__mod__? I'd alw
>> Please don't - not before % is actually deprecated (which I hope won't
>> happen until Python 4, with removal of % in Python 5, in the year
>> when I retire, i.e. 2037).
>
> Now this is news to me -- was there a discussion that changed the
> lifetime expectancy of str.__mod__? I'd always suppos
On Tue, Jun 3, 2008 at 2:03 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>>
>> Martin v. Löwis schrieb:
In any case, I'm willing to give the TLC to convert the whole stdlib
to str.format, so I just need your permission!
>>>
>>> Please don't - not before % is actua
Georg Brandl wrote:
Martin v. Löwis schrieb:
In any case, I'm willing to give the TLC to convert the whole stdlib
to str.format, so I just need your permission!
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the
Martin v. Löwis schrieb:
In any case, I'm willing to give the TLC to convert the whole stdlib
to str.format, so I just need your permission!
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the year
when I retire, i
> In any case, I'm willing to give the TLC to convert the whole stdlib
> to str.format, so I just need your permission!
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the year
when I retire, i.e. 2037).
Regards,
Mar
On Mon, Jun 2, 2008 at 5:49 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> As a newly converted fan of str.format, it gives me pangs to see the
> whole stdlib using "%." I realize that str.format is not quite up to
> the speed standards we'd like, but I'm sure that will change.
>
> In any case,
33 matches
Mail list logo
