+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,
Hi all,
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, I'm willing to give the TLC to convert the whole stdlib
to str.format, so I j
34 matches
Mail list logo
