On Thu, Aug 16, 2007, Guido van Rossum wrote:
>
> I don't know what percentage of %-formatting uses a string literal on
> the left; if it's a really high number (high 90s), I'd like to kill
> %-formatting and go with mechanical translation; otherwise, I think
> we'll have to phase out %-formatting
Eric Smith wrote:
> Ron Adam wrote:
>>
>> Martin v. Lo"wis wrote:
>>> Bill Janssen schrieb:
> I think most of these points are irrelevant. The curly braces are not
> just syntactic sugar, at least the opening brace is not; the digit
> is not syntactic sugar in the case of message tran
I think you should just disallow {...} for the start of the variable
reference. I.e. {0.{1}} is okay, but {{1}} is not.
On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
> >
> > Martin v. Lo"wis wrote:
> >> Bill Janssen schrieb:
> I think most of these points are irrelevant.
Eric Smith wrote:
> Ron Adam wrote:
>>
>> Martin v. Lo"wis wrote:
>>> Bill Janssen schrieb:
> I think most of these points are irrelevant. The curly braces are not
> just syntactic sugar, at least the opening brace is not; the digit
> is not syntactic sugar in the case of message tran
Ron Adam wrote:
>
> Martin v. Lo"wis wrote:
>> Bill Janssen schrieb:
I think most of these points are irrelevant. The curly braces are not
just syntactic sugar, at least the opening brace is not; the digit
is not syntactic sugar in the case of message translations.
>>> Are there "co
Martin v. Lo"wis wrote:
> Bill Janssen schrieb:
>>> I think most of these points are irrelevant. The curly braces are not
>>> just syntactic sugar, at least the opening brace is not; the digit
>>> is not syntactic sugar in the case of message translations.
>> Are there "computation of matching br
Martin v. Löwis wrote:
> Bill Janssen schrieb:
>>> I think most of these points are irrelevant. The curly braces are not
>>> just syntactic sugar, at least the opening brace is not; the digit
>>> is not syntactic sugar in the case of message translations.
>> Are there "computation of matching brace
Bill Janssen schrieb:
>> I think most of these points are irrelevant. The curly braces are not
>> just syntactic sugar, at least the opening brace is not; the digit
>> is not syntactic sugar in the case of message translations.
>
> Are there "computation of matching braces" problems here?
I don't
On 8/16/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > The only added wrinkle is that you can also write
> > {0!r} to *force* using repr() on the value.
>
> What if you want a field width with that? Will you be
> able to write {0!10r} or will it have to be {0!r:10}?
The la
Martin v. Löwis wrote:
> (it is then flawed also in that you don't typically
> have placeholders for the result fields and table name - not sure
> whether you even can in DB-API).
It probably depends on the underlying DB, but most DB
interfaces I know of don't allow such a thing.
My biggest gripe
[EMAIL PROTECTED] wrote:
> "{0} asks {1} if he is happy to see {1}".format('Brett', 'Skip',
> 'Christian')
>
> ^^^ whoops
This kind of mistake is easy to spot if the format
string is short.
If it's not short, it would be better to use names:
"{ask
Guido van Rossum wrote:
> The only added wrinkle is that you can also write
> {0!r} to *force* using repr() on the value.
What if you want a field width with that? Will you be
able to write {0!10r} or will it have to be {0!r:10}?
--
Greg
___
Python-3000
> I think most of these points are irrelevant. The curly braces are not
> just syntactic sugar, at least the opening brace is not; the digit
> is not syntactic sugar in the case of message translations.
Are there "computation of matching braces" problems here?
> That lots of people are familiar w
> But just saying you like %s over {0} is
> like saying you don't like the decorator syntax: that's nice and all,
> but that is not a compelling reason to change the decision being made.
My guess is that the folks who object to it are, like me, folks who
primarily work in Python and C, and don't w
> There's one other problem that I see, though it might be minor or
> infrequent enough not to matter. %s positional placeholders are
> easily to generate programmatically than {#} placeholders. Think
> about translating this:
>
> def make_query(flag1, flag2):
> base_query = 'SELECT
>* the new is more verbose than the old
>* the curly braces and [012]: prefixes are just syntactic sugar when
> converting old to new
>* in situations where the format string isn't a literal that mechanical
> translation from old to new won't be possible
>* lots of people
On 8/16/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
[SNIP]
> You are right. I'm guilty as charged to be a participant of a red bike
> shed discussion. :) I'm seeing myself as a small Python user and
> developer who is trying to get in touch with the gods in the temple of
> python core develop
On 8/16/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> But how is::
> "{0} is happy to see {1}".format('Brett', 'Christian')
> that less easier to read than::
> "%s is happy to see %s" % ('Brett', 'Christian')
Excluding minor aesthetics, they are equivalent.
The new format only has advanta
On Aug 16, 2007, at 4:19 PM, Brett Cannon wrote:
> Well, for me the "realness" of Py3K is the same now as it was back
> when Guido created teh p3yk branch.
Somehow, I suspect the reality of Python 3.0 for any individual is
strong tied to the amount of time they've had to read the emails,
PEPs,
[EMAIL PROTECTED] wrote:
> Brett> But how is::
>
> Brett> "{0} is happy to see {1}".format('Brett', 'Christian')
>
> Brett> that less easier to read than::
>
> Brett> "%s is happy to see %s" % ('Brett', 'Christian')
>
> Brett> ? Yes, PEP 3101 style is more to type
On 8/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> STeVe> I honestly can't see the point of keeping this::
>
> '%-10s bought %02i apples for %3.2f' % ('John', 8, 3.78)
> STeVe> 'John bought 08 apples for 3.78'
>
> STeVe> alongside this::
>
> '{0:-10
On 8/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brett> But how is::
>
> Brett> "{0} is happy to see {1}".format('Brett', 'Christian')
>
> Brett> that less easier to read than::
>
> Brett> "%s is happy to see %s" % ('Brett', 'Christian')
>
> Brett> ? Yes, PEP 31
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 16, 2007, at 3:52 PM, [EMAIL PROTECTED] wrote:
> STeVe> I honestly can't see the point of keeping this::
>
> '%-10s bought %02i apples for %3.2f' % ('John', 8, 3.78)
> STeVe> 'John bought 08 apples for 3.78'
>
> STeVe>
Brett Cannon wrote:
> [Tonight, the role of old, cranky python-dev'er will be played by
> Brett Cannon. Don't take this personally, Christian, your email just
> happened to be last. =)]
hehe :)
I don't feel offended.
> But how is::
>
> "{0} is happy to see {1}".format('Brett', 'Christian')
>
Brett> But how is::
Brett> "{0} is happy to see {1}".format('Brett', 'Christian')
Brett> that less easier to read than::
Brett> "%s is happy to see %s" % ('Brett', 'Christian')
Brett> ? Yes, PEP 3101 style is more to type but it isn't grievous; we
Brett> have just
STeVe> I honestly can't see the point of keeping this::
'%-10s bought %02i apples for %3.2f' % ('John', 8, 3.78)
STeVe> 'John bought 08 apples for 3.78'
STeVe> alongside this::
'{0:-10} bought {1:02i} apples for {2:3.2f}'.format('John', 8, 3.78)
STeVe
[Tonight, the role of old, cranky python-dev'er will be played by
Brett Cannon. Don't take this personally, Christian, your email just
happened to be last. =)]
On 8/16/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Alex> The PEP abstract says this proposal wil
On 8/16/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Alex> The PEP abstract says this proposal will replace the '%' operator,
>
> [...]
>
> I agree with Skip, too. The % printf operator is a very useful and
> powerful feature. I'm doing newbie support at my uni
[EMAIL PROTECTED] wrote:
> Alex> The PEP abstract says this proposal will replace the '%' operator,
[...]
I agree with Skip, too. The % printf operator is a very useful and
powerful feature. I'm doing newbie support at my university and in
#python. Newbies are often astonished how easy and po
On Aug 16, 2007, at 12:38 PM, Guido van Rossum wrote:
> I use it in the same way we used to refer to Python 3000 in the
> past. :-)
If we acknowledge that Python 3.0 isn't the same as Python 3000, we
don't even need a new name for it. ;-)
-Fred
--
Fred Drake
_
On 8/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Thanks for the detailed response.
>
> Guido> Now on to the transition. On the one hand I always planned this
> Guido> to *replace* the old %-formatting syntax, which has a number of
> Guido> real problems: "%s" % x raises an e
> Alex> The PEP abstract says this proposal will replace the '%' operator,
>
> I hope this really doesn't happen. printf-style formatting has a long
> history both in C and Python and is well-understood. Its few limitations
> are mostly due to the binary nature of the % operator, not to the
Guido van Rossum wrote:
> While we're not copying .NET *exactly*, most of the basic ideas are
> very similar; the discussion at this point is mostly about the
> type-specific mini-languages. My proposal is to use *exactly the same
> mini-language as used in 2.x %-formatting* (but without the '%'
>
Thanks for the detailed response.
Guido> Now on to the transition. On the one hand I always planned this
Guido> to *replace* the old %-formatting syntax, which has a number of
Guido> real problems: "%s" % x raises an exception if x happens to be a
Guido> tuple, and you have to wri
> > Alex> The PEP abstract says this proposal will replace the '%' operator,
> [EMAIL PROTECTED]:
> > I hope this really doesn't happen. printf-style formatting has a long
> > history both in C and Python and is well-understood. Its few limitations
> > are mostly due to the binary nature of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 16, 2007, at 8:29 AM, [EMAIL PROTECTED] wrote:
> Alex> The PEP abstract says this proposal will replace the '%'
> operator,
>
> I hope this really doesn't happen. printf-style formatting has a long
> history both in C and Python and is w
[EMAIL PROTECTED] schrieb:
> Alex> The PEP abstract says this proposal will replace the '%' operator,
>
> I hope this really doesn't happen. printf-style formatting has a long
> history both in C and Python and is well-understood. Its few limitations
> are mostly due to the binary nature of
Alex> The PEP abstract says this proposal will replace the '%' operator,
I hope this really doesn't happen. printf-style formatting has a long
history both in C and Python and is well-understood. Its few limitations
are mostly due to the binary nature of the % operator, not to the power or
38 matches
Mail list logo
