Michael Foord wrote:
Benjamin Peterson wrote:
2009/10/5 Nick Coghlan :
So I would agree that method invocation on literals (particularly string
literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
>
I've tried 4.__add__ a few times
Nick Coghlan wrote:
Benjamin Peterson wrote:
2009/10/8 Eric Smith :
Christian Tanzer wrote:
IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.
I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really worth n
Glenn Linderman wrote:
> If you want to replace a C program that produces parsed output in a
> given format, and that given format includes leading-0-octal numbers,
> then it would be good to have the capability in Python .format, even
> though Python itself uses 0o prefix.
>
> Similar arguments m
Benjamin Peterson wrote:
> 2009/10/8 Eric Smith :
>> Christian Tanzer wrote:
>>> IMHO, either the translation is done once and gives identical output or
>>> it isn't worth doing at all.
>> I disagree. I doubt even 0.001% of all format strings involve octal
>> formatting. Is it really worth not prov
On approximately 10/8/2009 7:24 AM, came the following characters from
the keyboard of Eric Smith:
Vinay Sajip wrote:
BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see
if it was
worth raising an enhancement request on the bug tracker using "O" to
generate
compatible renderin
On Thu, Oct 8, 2009 at 10:14 AM, Raymond Hettinger wrote:
> Do you think there may be some possible parallel to the -3 option
> to flag cases of %-formatting? If so, that could be helpful.
Absolutely. This should be simple, since there's just one or two
places where to place the warning. We migh
[Christian Tanzer]
How do you suppose that maintainers could ever do the transition from
%- to {}-formatting manually?
[Guido van Rossum]
This is pretty much the situation with integer division (you can only
recognize it by running the code),
Do you think there may be some possible parallel
On Thu, Oct 8, 2009 at 8:08 AM, Christian Tanzer wrote:
> All that talk of deprecating %-formatting makes me really nervous.
> %-formatting is pervasive in all existing Python code.
>
> Without an automatic translator that is 100% accurate, porting all
> that code to {}-formatting is not possible.
Benjamin Peterson python.org> writes:
> It's also really easy to just write 0{:o} like my translator does.
How does that cope when handed a negative number to format?
>>> "%#0o" % -1234
'-02322'
>>> "0{0:o}".format(-1234)
'0-2322'
Regards,
Vinay Sajip
__
2009/10/8 Eric Smith :
> Christian Tanzer wrote:
>> IMHO, either the translation is done once and gives identical output or
>> it isn't worth doing at all.
>
> I disagree. I doubt even 0.001% of all format strings involve octal
> formatting. Is it really worth not providing a transition path if it
Michael Foord wrote at Thu, 08 Oct 2009 16:56:35 +0100:
> > If %-formatting is first deprecated then removed from Python and there
> > is no automatic transition path that effectively means that existing
> > code using %-formatting is forced to stay at whatever Python version
> > was the last one
Christian Tanzer wrote:
[snip...]
IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.
I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really worth not providing a transition path if it
can't cover this
Eric Smith wrote:
Vinay Sajip wrote:
BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see
if it was
worth raising an enhancement request on the bug tracker using "O" to
generate
compatible rendering for octals.
I didn't get your message, could you resend?.
I was thinking the
Benjamin Peterson wrote:
2009/10/8 Eric Smith :
Christian Tanzer wrote:
IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.
I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really worth not providing a transi
Eric Smith wrote at Thu, 08 Oct 2009 10:24:33 -0400:
> Vinay Sajip wrote:
> > BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it
> > was
> > worth raising an enhancement request on the bug tracker using "O" to
> > generate
> > compatible rendering for octals.
>
> I didn't
Eric Smith wrote at Thu, 08 Oct 2009 10:55:21 -0400:
> >>> BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if
> >>> it was
> >>> worth raising an enhancement request on the bug tracker using "O" to
> >>> generate
> >>> compatible rendering for octals.
> >> I didn't get your
Christian Tanzer wrote:
Eric Smith wrote at Thu, 08 Oct 2009 10:24:33 -0400:
Vinay Sajip wrote:
BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was
worth raising an enhancement request on the bug tracker using "O" to generate
compatible rendering for octals.
I didn'
> I didn't get your message, could you resend?.
Resent, it may have been stopped by your spam filters since it came from my
vinay-underscore-sajip-at-red-hyphen-dove-dot-com address. The subject was
"Python str.format() and octal formatting compatibility".
> I was thinking the same thing, but
Vinay Sajip wrote:
BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was
worth raising an enhancement request on the bug tracker using "O" to generate
compatible rendering for octals.
I didn't get your message, could you resend?.
I was thinking the same thing, but it s
Nick Coghlan gmail.com> writes:
> Vinay's problem above is due to using the wrong alignment flag: ">",
> which says to right align everything, instead of "=", which says to left
> align the sign character and the numeric prefix with the fill character
> inserted in the middle. In this particular
Antoine Pitrou wrote:
> Vinay Sajip yahoo.co.uk> writes:
> "%0#8x" % 0x1234
>> '0x001234'
> "{0:0>#8x}".format(0x1234)
>> '000x1234'
>
> Apart from the sheer unreadability of the {}-style format string, the result
> looks rather unexpected from a human being's point of view.
The percent
Antoine Pitrou wrote:
Vinay Sajip yahoo.co.uk> writes:
"%0#8x" % 0x1234
'0x001234'
"{0:0>#8x}".format(0x1234)
'000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's point of view.
(in those situations, I would
Antoine Pitrou pitrou.net> writes:
>
> Vinay Sajip yahoo.co.uk> writes:
> >
> > >>> "%0#8x" % 0x1234
> > '0x001234'
> > >>> "{0:0>#8x}".format(0x1234)
> > '000x1234'
>
> Apart from the sheer unreadability of the {}-style format string, the result
> looks rather unexpected from a human being'
Vinay Sajip yahoo.co.uk> writes:
>
> >>> "%0#8x" % 0x1234
> '0x001234'
> >>> "{0:0>#8x}".format(0x1234)
> '000x1234'
Apart from the sheer unreadability of the {}-style format string, the result
looks rather unexpected from a human being's point of view.
(in those situations, I would output the
2009/10/4 INADA Naoki :
> What about using string prefix 'f'?
>
> f"{foo} and {bar}" % something == "{foo} and {bar}.format(something)
>
> s = f"{foo}"
> t = "%(bar)s"
> s + t # raises Exception
>
> Transition plan:
> n: Just add F prefix. And adding "format_string" in future.
> n+1: deprecate
On Fri, Oct 2, 2009 at 6:29 PM, Greg Ewing wrote:
> Has anyone considered the idea of having the string % operator
> behave intelligently according to the contents of the format
> string?
>
> If it contains one or more valid %-formats, use old-style
> formatting; if it contains one or more valid {
Martin v. Löwis wrote:
So if a decision was made to eventually remove % formatting, it would
be reasonable to start migrating code to PEP 3101. However, no such
decision has been made (and hopefully won't be throughout 3.x)
If it's not done during 3.x, then by the time 4.x comes
around, there
Has anyone considered the idea of having the string % operator
behave intelligently according to the contents of the format
string?
If it contains one or more valid %-formats, use old-style
formatting; if it contains one or more valid {}-formats,
use new-style formatting.
Ambiguous cases could a
Benjamin Peterson wrote:
2009/10/5 Nick Coghlan :
So I would agree that method invocation on literals (particularly string
literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
I've tried 4.__add__ a few times (not for a while n
2009/10/5 Nick Coghlan :
> So I would agree that method invocation on literals (particularly string
> literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
--
Regards,
Benjamin
___
Python-Dev mailing
2009/10/4 INADA Naoki :
>> -1 That requires keeping formatting information around in every string
>> instance.
> Adding new "format_string" class avoids it.
> unicode("foo") <=> u"foo"
> format_string("foo") <=> f"foo"
>
> This way's pros:
> * Many libraries can use one transition way.
> * Trans
Guido van Rossum wrote:
> \>> I hate calling methods on string literals, I think it looks very odd
>>> to have code like this:
>>>
>>> "Displaying {0} of {1} revisions".format(x, y)
>> Ugh! Good point.
>
> This objection was made years ago when we introduced
> "separator".join(list_of_things),
\>> I hate calling methods on string literals, I think it looks very odd
>> to have code like this:
>>
>> "Displaying {0} of {1} revisions".format(x, y)
>
> Ugh! Good point.
This objection was made years ago when we introduced
"separator".join(list_of_things), and I don't think ignoring it has
Martin v. Löwis wrote:
> That doesn't mean we have to have a transition plan *now*. Creating one
> after Python 3.5 is released (i.e. in 2015 or so) might be sufficient.
>
> To create a transition plan, you first need *consensus* that you
> actually do want to transition. I don't think such consen
MRAB mrabarnett.plus.com> writes:
> >>> "{0:#08x}".format(0x1234)
> '0x001234'
Good call, but here's another case:
>>> "%#o" % 0x1234
'011064'
I don't see how to automatically convert the "%#o" spec, though of course there
are ways of fudging it. The obvious conversion doesn't give the same v
Vinay Sajip wrote:
Raymond Hettinger rcn.com> writes:
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
I'm not sure you can always get equivalent output from the formatting, though.
For example:
"%0#8x" % 0x1234
'0x
2009/10/5 Vinay Sajip :
> Raymond Hettinger rcn.com> writes:
>> We should get one written. ISTM, every %-formatting
>> string is directly translatable to an equivalent {}-formatting string.
>
> I'm not sure you can always get equivalent output from the formatting, though.
> For example:
>
"%
Raymond Hettinger rcn.com> writes:
> We should get one written. ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.
I'm not sure you can always get equivalent output from the formatting, though.
For example:
>>> "%0#8x" % 0x1234
'0x001234'
>>> "{0:0
Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
>> I'm starting to think that a converter between the two format
>> mini-languages may be the way to go though.
>>
>> fmt_braces is meant to provide a superset of the capabilites of
>> fmt_percent, so a forward converter shouldn't be too hard
> I agree with this 100% but I can't see it working unless we have some
> sort of transition plan. Just saying "ok, switch your format strings
> from % to {}" didn't work in Python 3.0 for various good reasons, and
> I can't imagine it will work in Python 4.0 unless we have a transition
> plan.
Th
Carl Trachte wrote:
I've skimmed over the PEP, and the new {}-syntax seems to have some nice
features. But I've not seen it used anywhere yet.
I am using it with 3.1 in an unreleased book I am still writing, and
will in any code I publish.
Rami Chowdhury posted this to a mailing list; I'
> -1 That requires keeping formatting information around in every string
> instance.
Adding new "format_string" class avoids it.
unicode("foo") <=> u"foo"
format_string("foo") <=> f"foo"
This way's pros:
* Many libraries can use one transition way.
* Transition stage syncs to Python version. "l
What about using string prefix 'f'?
f"{foo} and {bar}" % something == "{foo} and {bar}.format(something)
s = f"{foo}"
t = "%(bar)s"
s + t # raises Exception
Transition plan:
n: Just add F prefix. And adding "format_string" in future.
n+1: deprecate __mod__() without 'F'.
n+2: libraries
>> Do the users get any say in this?
>
> I'm a user! :-)
>
> I hate calling methods on string literals, I think it looks very odd to
> have code like this:
>
> "Displaying {0} of {1} revisions".format(x, y)
>
> Will we be able to write this as
>
> "Displaying {0} of {1} revisions" % (x, y)
>
>
On Sat, Oct 3, 2009 at 11:05, Brett Cannon wrote:
> On Fri, Oct 2, 2009 at 20:03, Raymond Hettinger wrote:
>>
>> [Terry Reedy]
>>>
>>> I would agree, for instance, that an auto-translation tool is needed.
>>
>> We should get one written. ISTM, every %-formatting
>> string is directly translatabl
On 1 Oct 2009, at 10:37, M.-A. Lemburg wrote:
Eric Smith wrote:
Martin v. Löwis wrote:
Steven Bethard wrote:
There's a lot of code already out there (in the standard library
and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting.
I
Bugbee, Larry wrote:
> So until I see a *significant* benefit, my vote is *not* remove
> %-formatting. Make both available and if {} is to win, it will.
Percent formatting isn't going anywhere (certainly not for the next
decade or so). However, its well documented limitations (especially the
lack
2009/10/3 Brett Cannon :
> On Fri, Oct 2, 2009 at 20:03, Raymond Hettinger wrote:
>>
>> [Terry Reedy]
>>>
>>> I would agree, for instance, that an auto-translation tool is needed.
>>
>> We should get one written. ISTM, every %-formatting
>> string is directly translatable to an equivalent {}-form
MRAB mrabarnett.plus.com> writes:
> Interesting that you're using the %-format to translate %-formats to
> {}-formats!
Yes, ironic, isn't it? ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Vinay Sajip wrote:
Brett Cannon python.org> writes:
Why don't we start something in the sandbox and see how far we can
get. If no one beats me to it I will add the directory some time today
and we can start hashing out the solution there.
I've done a first cut of a converter from %-format t
2009/10/3 Vinay Sajip :
> Raymond Hettinger rcn.com> writes:
>
>> We should get one written. ISTM, every %-formatting
>> string is directly translatable to an equivalent {}-formatting string.
>>
>
> I've made a start, but I'm not sure how best to handle the '#' and ' '
> conversion flags.
Mine h
On Sat, Oct 3, 2009 at 15:27, Vinay Sajip wrote:
> Brett Cannon python.org> writes:
>
>> Why don't we start something in the sandbox and see how far we can
>> get. If no one beats me to it I will add the directory some time today
>> and we can start hashing out the solution there.
>>
>
> I've don
Raymond Hettinger rcn.com> writes:
> We should get one written. ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.
>
I've made a start, but I'm not sure how best to handle the '#' and ' '
conversion flags.
Regards,
Vinay Sajip
Nick Coghlan gmail.com> writes:
> I'm starting to think that a converter between the two format
> mini-languages may be the way to go though.
>
> fmt_braces is meant to provide a superset of the capabilites of
> fmt_percent, so a forward converter shouldn't be too hard. A reverse
> converter may
Brett Cannon python.org> writes:
> Why don't we start something in the sandbox and see how far we can
> get. If no one beats me to it I will add the directory some time today
> and we can start hashing out the solution there.
>
I've done a first cut of a converter from %-format to {}-format str
On Fri, Oct 2, 2009 at 20:03, Raymond Hettinger wrote:
>
> [Terry Reedy]
>>
>> I would agree, for instance, that an auto-translation tool is needed.
>
> We should get one written. ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.
Why don't we start
Paul Moore gmail.com> writes:
> Still tangential, but it seems to me that this discussion has exposed
> a couple of areas where the logging interface is less than ideal:
>
> - The introspection of the format string to delay computing certain
> items (Eric's suggestion may be an improvement here)
Paul Moore wrote:
2009/10/1 Eric Smith :
It's tangential, but in the str.format case you don't want to check for just
'{asctime}', because you might want '{asctime:%Y-%m-%d}', for example.
But there are ways to delay computing the time until you're sure it's
actually being used in the format
2009/10/1 Eric Smith :
> It's tangential, but in the str.format case you don't want to check for just
> '{asctime}', because you might want '{asctime:%Y-%m-%d}', for example.
>
> But there are ways to delay computing the time until you're sure it's
> actually being used in the format string, withou
Bugbee, Larry schrieb:
>>> Do the users get any say in this?
>>
>> I'm a user! :-)
>>
>> I hate calling methods on string literals, I think it looks very odd to
>> have code like this:
>>
>> "Displaying {0} of {1} revisions".format(x, y)
>
> Ugh! Good point.
>
> Is Python to be an easy-to-lea
On Oct 2, 2009, at 2:56 PM, Raymond Hettinger wrote:
Do the users get any say in this?
I imagine that some people are heavily invested in %-formatting.
Because there has been limited uptake on {}-formatting (afaict),
we still have limited experience with knowing that it is actually
better, less
> > Do the users get any say in this?
>
> I'm a user! :-)
>
> I hate calling methods on string literals, I think it looks very odd
> to have code like this:
>
> "Displaying {0} of {1} revisions".format(x, y)
Ugh! Good point.
Is Python to be an easy-to-learn-and-remember language? I submi
Raymond Hettinger wrote:
> Because there has been limited uptake on {}-formatting (afaict),
> we still have limited experience with knowing that it is actually
> better, less error-prone, easier to learn/rember, etc. Outside
> a handful of people on this list, I have yet to see anyone adopt
> it
Benjamin Peterson wrote:
2009/10/2 Raymond Hettinger :
[Terry Reedy]
I would agree, for instance, that an auto-translation tool is needed.
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
Yes, but not all are possible
Steven Bethard wrote:
> On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler wrote:
>> I hate calling methods on string literals, I think it looks very odd to
>> have code like this:
>>
>> "Displaying {0} of {1} revisions".format(x, y)
>>
>> Will we be able to write this as
>>
>> "Displaying {0} of {
2009/10/2 Raymond Hettinger :
>
> [Terry Reedy]
>>
>> I would agree, for instance, that an auto-translation tool is needed.
>
> We should get one written. ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.
Yes, but not all are possible to guess with
[Terry Reedy]
I would agree, for instance, that an auto-translation
tool is needed.
We should get one written. ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.
Raymond
___
Python-Dev mailing list
Pyt
Steven Bethard wrote:
On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy wrote:
As someone who likes .format() and who already uses such bound methods to
print, such as in
emsg = "...".format
...
if c: print(emsg(arg, barg))
I find this **MUCH** preferable to the ugly and seemingly unnecessary
wr
On Wed, Sep 30, 2009 at 05:29, Paul Moore wrote:
> 2009/9/30 Barry Warsaw :
>> Although I hate the name 'dicttemplate', this seems like the best solution
>> to me. Maybe it's good that 'dicttemplate' is so ugly though so that people
>> will naturally prefer 'format' :). But I like this because t
On Fri, Oct 2, 2009 at 11:56 AM, Raymond Hettinger wrote:
> [Steven Bethard]
>> Just saying "ok, switch your format strings
>> from % to {}" didn't work in Python 3.0 for various good reasons, and
>> I can't imagine it will work in Python 4.0 unless we have a transition
>> plan.
>
> Do the users g
On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler wrote:
> I hate calling methods on string literals, I think it looks very odd to
> have code like this:
>
> "Displaying {0} of {1} revisions".format(x, y)
>
> Will we be able to write this as
>
> "Displaying {0} of {1} revisions" % (x, y)
>
> too?
"Raymond Hettinger" writes:
> [Steven Bethard]
>>. Just saying "ok, switch your format strings
>> from % to {}" didn't work in Python 3.0 for various good reasons, and
>> I can't imagine it will work in Python 4.0 unless we have a transition
>> plan.
>
> Do the users get any say in this?
I'm a u
Raymond Hettinger rcn.com> writes:
>
> Because there has been limited uptake on {}-formatting (afaict),
> we still have limited experience with knowing that it is actually
> better, less error-prone, easier to learn/rember, etc.
It is known to be quite slower.
The following timings are on the p
[Steven Bethard]
. Just saying "ok, switch your format strings
from % to {}" didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.
Do the users get any say in this?
I imagine that some people are heavily invested in
On Fri, Oct 2, 2009 at 2:34 AM, Antoine Pitrou wrote:
> Steven Bethard gmail.com> writes:
>>
>> But it's not much of a transition plan. Or are you suggesting:
>
> The question is why we want a transition plan that will bother everyone with
> no
> tangible benefits for the user.
I think Guido ex
On Oct 2, 2009, at 5:34 AM, Antoine Pitrou wrote:
Steven Bethard gmail.com> writes:
But it's not much of a transition plan. Or are you suggesting:
The question is why we want a transition plan that will bother
everyone with no
tangible benefits for the user.
Forcing a transition to {}-
Steven Bethard gmail.com> writes:
>
> But it's not much of a transition plan. Or are you suggesting:
The question is why we want a transition plan that will bother everyone with no
tangible benefits for the user.
Regards
Antoine.
___
Python-Dev mai
On Thu, Oct 1, 2009 at 15:19, Steven Bethard wrote:
> On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon wrote:
>> So I created this last night:
>>
>> import collections
>>
>> class braces_fmt(str):
>>
>> def __mod__(self, stuff):
>> if isinstance(stuff, tuple):
>> return self.__c
On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy wrote:
> As someone who likes .format() and who already uses such bound methods to
> print, such as in
>
> emsg = "...".format
> ...
> if c: print(emsg(arg, barg))
>
> I find this **MUCH** preferable to the ugly and seemingly unnecessary
> wrapper cla
Antoine Pitrou wrote:
Vinay Sajip yahoo.co.uk> writes:
Does it seems too onerous to expect people to pass an additional "use_format"
keyword argument with every logging call to indicate how to interpret the
message format string? Or does the PercentMessage/BraceMessage type approach
have any mi
On Thu, Oct 1, 2009 at 4:35 PM, Brett Cannon wrote:
> On Thu, Oct 1, 2009 at 15:19, Steven Bethard wrote:
>> On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon wrote:
>>> class braces_fmt(str):
>>>
>>> def __mod__(self, stuff):
>>> if isinstance(stuff, tuple):
>>> return self.__c
On Thu, Oct 1, 2009 at 14:54, Nick Coghlan wrote:
> Vinay Sajip wrote:
>> So there's no need to change modules like logging to explicitly
>> provide support for {}-formatting? What's not to like? ;-) Something
>> like this perhaps should have been added in at the same time as
>> str.format went in
On Oct 1, 2009, at 6:19 PM, Steven Bethard wrote:
I see how this could allow a user to supply a {}-format string to an
API that accepts only %-format strings. But I still don't see the
transition strategy for the API itself. That is, how does the %-format
API use this to eventually switch to {}-f
Vinay Sajip wrote:
Good point as far as the general case is concerned, though it's perhaps not that
critical for logging. By which I mean, it's not unreasonable for
Formatter.__init__ to grow a "style" keyword parameter which determines whether
it uses %-, {}- or $-formatting. Then the formatter
Nick Coghlan gmail.com> writes:
> I believe classes like fmt_braces/fmt_dollar/fmt_percent will be part of
> a solution, but they aren't a complete solution on their own. (Naming
> the three major string formatting techniques by the key symbols involved
> is a really good idea though)
>
> The tw
On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon wrote:
> So I created this last night:
>
> import collections
>
> class braces_fmt(str):
>
> def __mod__(self, stuff):
> if isinstance(stuff, tuple):
> return self.__class__(self.format(*stuff))
> elif isinstance(stuff, coll
James Y Knight fuhm.net> writes:
> Using containment instead of inheritance makes sure none of the
> *other* operations people do on strings will appear to work, at least
> (substring, contains, etc). I bet explicitly calling str() on a format
> string is even more rare than attempting to d
On Oct 1, 2009, at 5:54 PM, Nick Coghlan wrote:
I believe classes like fmt_braces/fmt_dollar/fmt_percent will be
part of
a solution, but they aren't a complete solution on their own. (Naming
the three major string formatting techniques by the key symbols
involved
is a really good idea though
Vinay Sajip wrote:
> So there's no need to change modules like logging to explicitly
> provide support for {}-formatting? What's not to like? ;-) Something
> like this perhaps should have been added in at the same time as
> str.format went in.
I believe classes like fmt_braces/fmt_dollar/fmt_perce
Vinay Sajip wrote:
> You're right to be nervous: it's not hard to mangle subtypes.
>
class mystr(str): pass
> ...
s = mystr("Abc")
s
> 'Abc'
type(s)
>
s2 = s.replace("A", "a")
s2
> 'abc'
type(s2)
>
It's also difficult for the subclass to prevent this without c
> So I created this last night:
>
> import collections
>
> class braces_fmt(str):
>
> def __mod__(self, stuff):
> if isinstance(stuff, tuple):
> return self.__class__(self.format(*stuff))
> elif isinstance(stuff, collections.Mapping):
> return self.__
Glenn Linderman wrote:
> 1) Both the format message and all the parameters are supplied in a
> single API call. This is really a foolish API, because
>
>def API( fmt, p1, p2, p3 ):
> str = fmt % (p1, p2, p3)
>
> could have just as easily been documented originally as
>
>def API( str
On Thu, Oct 1, 2009 at 06:29, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> This seems to me to be almost the same as the previous suggestion of
>> having a string subclass:
>>
>> class BraceFormatter(str):
>> def __mod__(self, other):
>> # Needs more magic here to cope with
On approximately 9/30/2009 4:03 PM, came the following characters from
the keyboard of Vinay Sajip:
Steven Bethard gmail.com> writes:
There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-
Raymond Hettinger rcn.com> writes:
> It looks like the BraceMessage would have to re-instantiate on every
> invocation.
True, because the arguments to the instantiation are kept around as a
BraceMessage instance until the time comes to actually format the message
(which might be never). Since ty
On Sep 30, 2009, at 1:01 PM, Antoine Pitrou wrote:
Why not allow logging.Formatter to take a callable, which would in
turn call the
callable with keyword arguments?
Therefore, you could write:
logging.Formatter("{asctime} - {name} - {level} - {msg}".format)
and then:
logging.critical(name
[Vinay Sajip]
And the special wrappers needn't be too intrusive:
__ = BraceMessage
logger.debug(__("Message with {0} {1}", 1, "argument"))
It looks like the BraceMessage would have to re-instantiate on every invocation.
Raymond
___
Python-Dev mai
On Oct 1, 2009, at 9:11 AM, Paul Moore wrote:
This seems to me to be almost the same as the previous suggestion of
having a string subclass:
class BraceFormatter(str):
def __mod__(self, other):
# Needs more magic here to cope with dict argument
return self.format(*other)
__ =
Antoine Pitrou pitrou.net> writes:
> There's another possibility, which is to build the wrapping directly around
> the
> logger. That is, if I want a %-style logger, I do:
>
>logger = logging.getLogger("smtp")
>logger.debug("incoming email from %s", sender_address)
>
> and I want a {}-
Paul Moore gmail.com> writes:
> 2. The internal implementation of logger.debug needs to preserve
> string subclasses properly
>
> But the benefit is that the approach allows anyone to use brace
> formatting in any API that currently accepts % format (assuming string
> subclasses don't get mangle
1 - 100 of 141 matches
Mail list logo
