Re: [Python-Dev] transitioning from % to {} formatting
Vinay Sajip yahoo.co.uk> writes: > #Just typing this in, it's not tested or anything > class DollarMessage: > def __init__(self, fmt, *args, **kwargs): > self.fmt = fmt > self.args = args > self.kwargs = kwargs > > def __str__(self): > return string.Template(self.fmt).substitute(*args, **kwargs) > Whoops, sorry, pressed the "post" button by accident on my previous post. The above substitute call should of course say string.Template(self.fmt).substitute(*self.args, **self.kwargs) and you can alias DollarMessage (or whatever name you choose) as _ or __, say. As far as the Formatter formatting goes, it's easy enough to subclass Formatter to format using whatever approach you want. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
Brett Cannon python.org> writes:
> As for the PercentMessage/BraceMessage, I would make sure that you
> just simply take the string format and simply apply the arguments
> later to cut down on the amount of parentheses butting up against each
> other: ``logger.debug(BraceMessage("The {} is {}"), "answer", 42)``.
The problem with that is that BraceMessage.__str__() wouldn't know what
arguments to use to produce the message.
> cost of wrapping all strings for a while. I suspect most people will
> simply import the wrapping class and give it some short name like
> people do with gettext.
>
Yes,
logger.debug(__("The {} is {}", "answer", 42))
isn't ideal but perhaps liveable with. And hopefully with a decent editor, the
paren-butting annoyance will be minimized.
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
Barry Warsaw wrote: > If not, I'll try to > spend some time over the next few days looking at outstanding bugs, and > marking release blockers, etc. I'd like to draw attention to: http://bugs.python.org/issue5949 Which is a regression of imaplib.py introduced in r57680. Ever since I switched to python 2.6 on my box, I have had issues with getmail[1] getting stuck in an infinite loop swallowing memory (note: only applies to IMAP SSL connections). While this code is present in older versions of python, it seems to have become a problem recently (2009-05-06 is the earliest report on the issue) perhaps due to a version bump of OpenSSL? I never noticed the problem in python2.5 even though the code is unchanged. Nevertheless, the code is clearly wrong and should be corrected. I would appreciate this bug being resolved before the next release as it effects me on a daily basis. I have submitted a patch, which reflects my local solution. -Scott [1] http://pyropus.ca/software/getmail/ -- Scott Dial [email protected] [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
Scott Dial wrote: > While this code is present in > older versions of python, it seems to have become a problem recently > (2009-05-06 is the earliest report on the issue) perhaps due to a > version bump of OpenSSL? I never noticed the problem in python2.5 even > though the code is unchanged. To answer my own question, this was introduced in r64578 in ssl.py by the addition of the suppress_ragged_eofs feature (seems to originate with issue1251). While it is a change in the behavior of the ssl module, the change falls in line with other file-like objects and their handling of EOF, so the bug still falls to imaplib. In other words, this bug appeared in 2.6 and 3.0, and is present in all subsequent versions. -- Scott Dial [email protected] [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
2009/9/30 Robert Kern : > I am blissfully unaware of the problems Paul mentioned about Windows GUI-mode > programs. :-) > I'm not sure what would make a program "GUI-mode" or not. Certainly, I have > written > Python programs that use wxPython and PyQt on Windows that print to > stdout/stderr, > and they appear to work fine. It's the difference between using python.exe and pythonw.exe. There's a flag in the executable header saying whether the executable is "console mode" or "gui mode". GUI mode programs are run (by the OS) without a console (or if run from a console prompt, they automatically detach from that console, much like Unix programs which fork themselves to leave the terminal group (did I get the terminology right?) but done by the OS). As a result, the program has no valid stdin/out/err handles. Any attempt to write to them causes the program to crash. Traceback (most recent call last): File "hello.py", line 13, in main() File "hello.py", line 7, in main sys.stdout.flush() IOError: [Errno 9] Bad file descriptor (Question - is it *ever* possible for a Unix program to have invalid file descriptors 0,1 and 2? At startup - I'm assuming anyone who does os.close(1) knows what they are doing!) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 don't agree that we should do that. I see nothing wrong with using
>> % substitution.
I agree with Martin.
Both approaches have their ups and downs, but forcing users to move
from %-formatting to .format()-formatting will just frustrate them:
having to convert several thousand such (working) uses in their code
with absolutely no benefit simply doesn't look like a good way to
spend your time.
In addition to the code changes, such a move would also render
existing translations of the %-formatted string templates useless.
> It's a maintenance burden. There are several outstanding bugs with it,
> admittedly not of any great significance. I've been putting time into
> fixing at least one of them. When Mark and I did short-float-repr, at
> least half of my time was consumed with %-formatting, mostly because of
> how it does memory management.
Why not allow both and use .format() for those cases where %-formatting
doesn't work too well ?
> On the plus side, %-formatting is (and always will be) faster than
> str.format(). Its very limitations make it possible for it to be fast.
>
> I'd note that PEP 3101 calls str.format() a replacement for
> %-formatting, not an alternate mechanism to achieve the same end.
I think that's a wording we should change.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Oct 01 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OT: detatching from terminal (was: Re: PEP 389: argparse - new command line parsing module)
On Thu, Oct 01, 2009 at 09:58:59AM +0100, Paul Moore wrote: > (Question - is it *ever* possible for a Unix program to have invalid > file descriptors 0,1 and 2? At startup - I'm assuming anyone who does > os.close(1) knows what they are doing!) Normally you don't close fd 0, 1 & 2 but rather redirect them to /dev/null (a black hole). That saves you from nastiness when a library or something misbahaves and tries to use one of those. It would have been nice if windows GUI-mode programs as you describe them would do something similar. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Thu, Oct 01, 2009 at 09:58:59AM +0100, Paul Moore wrote: > (Question - is it *ever* possible for a Unix program to have invalid > file descriptors 0,1 and 2? At startup - I'm assuming anyone who does > os.close(1) knows what they are doing!) Yes, at startup you just have the file descriptors your parent process gave you. This may or may not include 0, 1, and 2, and may or may not include other descriptors too. I seem to recall there have been security holes caused in the past by people assuming 0-2 will exist. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
Vinay Sajip yahoo.co.uk> writes:
>
> This seems perhaps usable for a Formatter instantiation (infrequent) but a
> problem for the case where you want to convert format_str + args -> message
> (potentially frequent, and less readable).
Why is it a problem? I don't understand. It certainly is less pleasant to write
"{foo}".format or "{0} {1}".format than it is to write "{0} {1}" alone, but it's
still prettier and easier to remember than the special wrappers people are
proposing here.
> Another problem is that logging
> calls already use keyword arguments (extra, exc_info) and so backward
> compatibility might be compromised.
Then logging can just keep recognizing those special keyword arguments, and
forward the others to the formatting function.
> It also feels like passing a callable could
> encourage patterns of usage which restrict our flexibility for future changes:
Which future changes are you thinking about? AFAIK, there hasn't been a single
change in logging output formatting in years. Rejecting a present change on the
basis that it "restricts our flexibility for future changes" sounds like the
worst kind of argument to me :-)
> That's more flexible, to be sure, but more specialized formatting
> requirements are already catered for using e.g. the
> PercentMessage/BraceMessage
> approach.
Except that having to wrap format strings with "PercentMessage" or
"BraceMessage" is horrible. Python is not Java.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
Scott Dial wrote: > I would appreciate this bug being resolved before the next release as it > effects me on a daily basis. I have submitted a patch, which reflects my > local solution. Unfortunately, it's almost certainly too late to get this into 2.6.3. It really needed to be brought up back when Barry called for identification of significant 2.6 bugs and patches rather than after the RC had already been released. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
On Oct 1, 2009, at 2:51 AM, Vinay Sajip wrote: You're already covered if you use the PercentMessage/BraceMessage approach I mentioned elsewhere in this thread. Suppose: #Just typing this in, it's not tested or anything class DollarMessage: def __init__(self, fmt, *args, **kwargs): self.fmt = fmt self.args = args self.kwargs = kwargs def __str__(self): return string.Template(self.fmt).substitute(*args, **kwargs) Right, thanks. This is a very cool feature that I didn't know logging supported! -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
On Oct 1, 2009, at 7:09 AM, Nick Coghlan wrote: Scott Dial wrote: I would appreciate this bug being resolved before the next release as it effects me on a daily basis. I have submitted a patch, which reflects my local solution. Unfortunately, it's almost certainly too late to get this into 2.6.3. It really needed to be brought up back when Barry called for identification of significant 2.6 bugs and patches rather than after the RC had already been released. Right. Scott, you can get reviews and support for the patch now so that the bug can be addressed in 2.6.4. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
Antoine Pitrou pitrou.net> writes:
>
> Why is it a problem? I don't understand. It certainly is less pleasant to
> write "{foo}".format or "{0} {1}".format than it is to write "{0} {1}" alone,
> but it's still prettier and easier to remember than the special wrappers
> people are proposing here.
Well, it's less readable, as I said in parentheses. It would work, of course.
And the special wrappers needn't be too intrusive:
__ = BraceMessage
logger.debug(__("Message with {0} {1}", 1, "argument"))
> Then logging can just keep recognizing those special keyword arguments, and
> forward the others to the formatting function.
It just means that you can't pass those values through, and what if some of
them are used somewhere in existing code?
> > It also feels like passing a callable could
> > encourage patterns of usage which restrict our flexibility for future
> > changes:
>
> Which future changes are you thinking about? AFAIK, there hasn't been a
It's the Rumsfeldian "We don't know what we don't know" ;-)
> single change in logging output formatting in years. Rejecting a present
> change on the basis that it "restricts our flexibility for future changes"
> sounds like the worst kind of argument to me
Now don't get upset and take it as a rejection, as we're still in the
kicking-ideas-around stage ;-) I'm just saying how it feels to me.
I agree that logging output formatting hasn't changed in years, and that's
because there's been no particular need for it to change (some changes *were*
made in the very early days to support a single dict argument). Now that time
for change has perhaps come.
I'm just trying to think ahead, and can't claim to have got a definitive answer
up my sleeve. Passing a callable has upsides and downsides, and ISTM it's
always worth focusing on the downsides to make sure they don't come back and
bite you later. I don't foresee any specific problem - I'm just uneasy about
it.
> Except that having to wrap format strings with "PercentMessage" or
> "BraceMessage" is horrible. Python is not Java.
Amen. I'd say "Yeccchh!" too, if it literally had to be like that. And I also
note that there are voices here saying that support for %-formatting shouldn't,
or doesn't need to, change, at least until Python 4.0.
So consider the following tentative suggestion, which is off the top of my head
and offered as a discussion point:
Suppose that if you want to use %-formatting, everything stays as is. No
backward-compatibility headaches.
To support {}-formatting, add an extra class which I've called BraceMessage.
Consider this name a "working title", as no doubt a better name will suggest
itself, but for now this name makes it clear what we're talking about.
If any module wants to use {} formatting for their logging, they can add the
line
from logging import BraceMessage as __
I've used two underscores, since _ might be being used for gettext, but
obviously the importer can use whatever name they want.
and then they can use
logger.debug(__("The {0} is {1}", "answer", 42))
which I think is more readable than putting in ".format" following the string
literal. It's not a *huge* point, perhaps, but "Readability counts".
This has the side benefit that if e.g. Barry wanted to use string.Template for
formatting, he's just got to replace the above import with something like
from logging import DollarMessage as __
Another "working title", please note. And while I've shown these classes being
imported from logging, it doesn't make sense to put them there if this idea
were to fly in a more general context. Then, perhaps string would be a better
home for these classes.
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
Hello,
> Well, it's less readable, as I said in parentheses. It would work, of course.
> And the special wrappers needn't be too intrusive:
>
> __ = BraceMessage
>
> logger.debug(__("Message with {0} {1}", 1, "argument"))
Ah, I hadn't thought about that. It looks a bit less awful indeed.
I'm of the opinion, however, that %-formatting should remain the default and
shouldn't need a wrapper.
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 {}-style logger, I do:
logger = logging.getLogger("smtp", style="{}")
logger.debug("incoming email from {addr}", addr=sender_address)
(of course, different users of the "smtp" logger can request different
formatting styles when calling getLogger().)
We could combine the various proposals to give users flexible APIs. Of course,
it generally smells of "there's more than one way to do it".
> It's the Rumsfeldian "We don't know what we don't know"
Is this guy in the Python community? :-)
> I'm just trying to think ahead, and can't claim to have got a definitive
> answer
> up my sleeve.
Sure, we have some time until 2.7/3.2 anyway.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
2009/10/1 Vinay Sajip :
> If any module wants to use {} formatting for their logging, they can add the
> line
>
> from logging import BraceMessage as __
>
> I've used two underscores, since _ might be being used for gettext, but
> obviously the importer can use whatever name they want.
>
> and then they can use
>
> logger.debug(__("The {0} is {1}", "answer", 42))
>
> which I think is more readable than putting in ".format" following the string
> literal. It's not a *huge* point, perhaps, but "Readability counts".
>
> This has the side benefit that if e.g. Barry wanted to use string.Template for
> formatting, he's just got to replace the above import with something like
>
> from logging import DollarMessage as __
>
> Another "working title", please note. And while I've shown these classes being
> imported from logging, it doesn't make sense to put them there if this idea
> were to fly in a more general context. Then, perhaps string would be a better
> home for these classes.
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)
__ = BraceFormatter
logger.debug(__("The {0} is {1}"), "answer", 42)
The only real differences are
1. The positioning of the closing parenthesis
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 mangled).
On the one hand, I'd prefer a more general solution. On the other, I'm
nervous about that "assuming string subclasses..." proviso.
I've no real answer, just offering the point up for consideration.
Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 dict argument
> return self.format(*other)
>
> __ = BraceFormatter
>
> logger.debug(__("The {0} is {1}"), "answer", 42)
>
> The only real differences are
>
> 1. The positioning of the closing parenthesis
> 2. The internal implementation of logger.debug needs to preserve
> string subclasses properly
>
The other difference is that my suggestion supports Barry's desire to use
string.Template with no muss, no fuss ;-) Plus, very little additional work is
required compared to your items 1 and 2. ISTM BraceMessage would be something
like this,
clsss BraceMessage:
def __init__(self, fmt, *args, **kwargs):
self.fmt = fmt
self.args = args
self.kwargs = kwargs
def __str__(self):
return self.fmt.format(*self.args, **self.kwargs)
Regards,
Vinay
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 mangled).
>
> On the one hand, I'd prefer a more general solution. On the other, I'm
> nervous about that "assuming string subclasses..." proviso.
>
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)
>>>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 {}-style logger, I do:
>
>logger = logging.getLogger("smtp", style="{}")
>logger.debug("incoming email from {addr}", addr=sender_address)
>
> (of course, different users of the "smtp" logger can request different
> formatting styles when calling getLogger().)
There's a LoggerAdapter class already in the system which is used to wrap
loggers so that additional contextual information (e.g. network or database
connection information) can be added to logs. The LoggerAdapter could fulfill
this "wrapping" function.
> We could combine the various proposals to give users flexible APIs. Of course,
> it generally smells of "there's more than one way to do it".
Yeah, that bothers me too.
> > It's the Rumsfeldian "We don't know what we don't know"
>
> Is this guy in the Python community?
Not sure, but I believe he's a piece of work and not a guy to get on the wrong
side of ;-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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)
__ = BraceFormatter
logger.debug(__("The {0} is {1}"), "answer", 42)
I'd rather make that:
class BraceFormatter:
def __init__(self, s):
self.s = s
def __mod__(self, other):
# Needs more magic here to cope with dict argument
return s.format(*other)
__ = BraceFormatter
That is, *not* a string subclass. Then if someone attempts to mangle
it, or use it for anything but %, it fails loudly.
James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
[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 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
Scott Dial wrote: > Scott Dial wrote: > > While this code is present in > > older versions of python, it seems to have become a problem recently > > (2009-05-06 is the earliest report on the issue) perhaps due to a > > version bump of OpenSSL? I never noticed the problem in python2.5 even > > though the code is unchanged. > > To answer my own question, this was introduced in r64578 in ssl.py by > the addition of the suppress_ragged_eofs feature (seems to originate > with issue1251). While it is a change in the behavior of the ssl module, > the change falls in line with other file-like objects and their handling > of EOF, so the bug still falls to imaplib. > > In other words, this bug appeared in 2.6 and 3.0, and is present in all > subsequent versions. Thanks for bringing this up, Scott. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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="Python", msg="Buildbots are down")
All this without having to learn about a separate "compatibility
wrapper object".
It's a nice idea -- but I think it's better for the wrapper (whatever
form it takes) to support __mod__ so that logging.Formatter (and
everything else) doesn't need to be modified to be able to know about
how to use both callables and "%"ables.
Is it possible for a C function like str.format to have other methods
defined on its function type?
James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 typically in performance-sensitive code, the
isEnabledFor pattern is used to avoid doing unnecessary work, as in
if logger.isEnabledFor(logging.DEBUG):
logger.debug(__("The {0} is {1}", "answer", 42))
The BraceMessage invocation overhead is only incurred when needed, as is the
cost of computing the additional arguments.
As I understand it {}-formatting is slower than %-formatting anyway, and if
this pattern is used only for {}-formatting, then there will be no additional
overhead for %-formatting and some additional overhead for {}-formatting. I'm
not sure what that instantiation cost will be relative to the overall time for
an "average" call - whatever that is ;-) - though.
Other approaches to avoid instantiation could be considered: for example,
making __ a callable which remembers previous calls and caches instances keyed
by the call arguments. But this will incur memory overhead and some processing
overhead and I'm not sure if it really buys you enough to warrant doing it.
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 {}-style formatting. We should really provide
some sort of transition plan. Consider an example from the logging
docs:
logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
We'd like to support both this style as well as the following style:
logging.Formatter("{asctime} - {name} - {levelname} - {message}")
In logging at least, there are two different places where the formatting issue
crops up.
The first is creating the "message" part of the the logging event, which is
made up of a format string and arguments.
The second is the one Steven's mentioned: formatting the message along with
other event data such as time of occurrence, level, logger name etc. into the
final text which is output.
It seems to me that most of the discussion of in this thread is
concerned with the first issue... and yet I see the second as the harder
issue, and it has gotten less press.
Abstracting this away from logger, I think the problem has three cases:
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 ):
where the user is welcome to supply a string such as
API( fmt % (p1, p2, p3 ))
and if done this way, the conversion to .format is obvious... and all
under the users control.
2) The format message and the parameters are supplied to separate APIs,
because the format message is common to many invocations of the other
APIs that supply parameters, and is cached by the API. This is
sufficient to break the foolishness of #1, but is really just a subset
of #3, so any solutions to #3 apply here.
3) The format message and the parameters for it may be supplied by the
same or separate APIs, but one or both are incomplete, and are augmented
by the API. In other words, one or both of the following cases:
3a) The user supplied format message may include references to named
parameters that are documented by the API, and supplied by the API,
rather than by the user.
3b) The user supplied format string may be embedded into a larger format
string by the API, which contains references to other values that the
user must also supply.
In either case of 3a or 3b, the user has insufficient information to
perform the whole format operation and pass the result to the API.
In both cases, the API that accepts the format string must be informed
whether it is a % or {} string, somehow. This could be supplied to the
API that accepts the string, or to some other related API that sets a
format mode. Internally, the code would have to be able to manipulate
both types of formats.
Support for both % and {} forms in logging would need to be considered in
these two places. I sort of liked Martin's proposal about using different
keyword arguments, but apart from the ugliness of "dicttemplate" and the fact
that "fmt" is already used in Formatter.__init__ as a keyword argument, it's
possible that two different keyword arguments "fmt" and "format" both referring
to format strings might be confusing to some users.
Benjamin's suggestion of providing a flag to Formatter seems slightly better,
as it doesn't change what existing positional or keyword parameters do, and
just adds an additional, optional parameter which can start off with a default
of False and transition to a default of True.
However, AFAICT these approaches only cover the second area where formatting
options are chosen - not the creation of the message from the parameters passed
to the logging call itself.
The above three paragraphs are unclear to me. I think they might be
referring to case 2 or 3, though.
Of course one can pass arbitrary objects as messages which contain their own
formatting logic. This has been possible since the very first release but I'm
not sure that it's widely used, as it's usually easier to pass strings. So
instead of passing a string and arguments such as
logger.debug("The %s is %d", "answer", 42)
one can currently pass, for a fictitious class PercentMessage,
logger.debug(PercentMessage("The %s is %d", "answer", 42))
and when the time comes to obtain the formatted message, LogRecord.getMessage
calls str() on the PercentMessage instance, whose __str__ will use %-formatting
to get the actual message.
Of course, one can also do for example
logger.debug(BraceMessage("The {} is {}", "answer", 42))
where the __str__() method on the BraceMessage will do {} formatting.
Of course, I'm not suggesting we actually use the names PercentMessage and
BraceMessage, I've just used them there for clarity.
It seems that the above
Re: [Python-Dev] Python 2.6.3
Nick Coghlan wrote: > Scott Dial wrote: >> I would appreciate this bug being resolved before the next release as it >> effects me on a daily basis. I have submitted a patch, which reflects my >> local solution. > > Unfortunately, it's almost certainly too late to get this into 2.6.3. It > really needed to be brought up back when Barry called for identification > of significant 2.6 bugs and patches rather than after the RC had already > been released. > I understand. I didn't figure out the bug until after rc1 landed. It was only happening spuriously with my mail server, never when I manually tried to invoke the problem. I was forced to let my cronjob run until the kernel killed getmail for OOM, giving me the trace shown in the issue. It is impossible to break anything with this patch, as no program could proceed. The 3-line patch merely converts it back into the exception that was originally raised prior to 2.6, so it's not a new behavior in that respect either. I wouldn't have anticipated this much resistance to removing an infinite loop from the standard library. I could also for this patch from the angle that it allows a remote host the ability to execute a denial-of-service attack (even by accident!) since the infinite loop appends an empty string to a list on every loop, taking CPU time and memory with it. Allow me to be naive for a moment and say, is this not the point of rc1 but to catch bugs that should not be in the final? Of course, it's Barry's call. -- Scott Dial [email protected] [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 dict argument
>> return self.format(*other)
>>
>> __ = BraceFormatter
>>
>> logger.debug(__("The {0} is {1}"), "answer", 42)
>>
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.__class__(self.format(**stuff))
else:
return self.__class__(self.format(stuff))
The biggest issue is that ``"%s" % {'a': 42}`` substitutes the dict
instead of throwing an error that str.format() would do with the code
above. But what's nice about this is I think I can use this now w/ any
library that expects % interpolation and it should basically work.
>> The only real differences are
>>
>> 1. The positioning of the closing parenthesis
>> 2. The internal implementation of logger.debug needs to preserve
>> string subclasses properly
>>
>
> The other difference is that my suggestion supports Barry's desire to use
> string.Template with no muss, no fuss ;-)
I don't think Paul's suggestion requires much more work to support
string.Template, simply a subclass that implements __mod__>
> Plus, very little additional work is
> required compared to your items 1 and 2. ISTM BraceMessage would be something
> like this,
>
> clsss BraceMessage:
> def __init__(self, fmt, *args, **kwargs):
> self.fmt = fmt
> self.args = args
> self.kwargs = kwargs
>
> def __str__(self):
> return self.fmt.format(*self.args, **self.kwargs)
I guess my question is what's the point of the class if you are simply
converting it before you pass it in to the logger? To be lazy about
the formatting call? Otherwise you could simply call str.format() with
your arguments before you pass the string into the logger and not have
to wrap anything.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
On Oct 1, 2009, at 1:47 PM, Scott Dial wrote: Allow me to be naive for a moment and say, is this not the point of rc1 but to catch bugs that should not be in the final? Actually, no. The point of an rc is to avoid a brown paper bag mistake, i.e. something we really fscked up in the release like breaking "import sys" or the build process, etc. We're always gonna have bugs, so that can't be it. :) -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 ): > > where the user is welcome to supply a string such as > >API( fmt % (p1, p2, p3 )) > > and if done this way, the conversion to .format is obvious... and all > under the users control. The lazy APIs actually make a lot of sense, particularly when there is a chance that the function being called may be able to avoid the formatting call altogether. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
> 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.__class__(self.format(**stuff))
> else:
> return self.__class__(self.format(stuff))
>
> The biggest issue is that ``"%s" % {'a': 42}`` substitutes the dict
> instead of throwing an error that str.format() would do with the code
> above. But what's nice about this is I think I can use this now w/ any
> library that expects % interpolation and it should basically work.
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 don't think Paul's suggestion requires much more work to support
> string.Template, simply a subclass that implements __mod__
True.
> I guess my question is what's the point of the class if you are simply
> converting it before you pass it in to the logger? To be lazy about
> the formatting call? Otherwise you could simply call str.format() with
> your arguments before you pass the string into the logger and not have
> to wrap anything.
That's exactly the reason - to defer the formatting until it's needed.
Otherwise you can always format the string yourself,as you say, and pass it as
the single argument in the logging call - logging won't know or care if it was
passed in as a literal, or was computed by %-, {}-, $- or any other formatting
approach.
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 creating an
infinite loop... (I only spent about 10 minutes looking into it the
other day, but that's what happened in all of my naive attempts at doing
it in pure Python code).
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
On Wed, 30 Sep 2009 13:06:47 -0700, Sridhar Ratnakumar wrote: On Wed, 30 Sep 2009 12:44:14 -0700, Barry Warsaw wrote: 2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows 32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did. Thanks for the feedback! Did you run the test suite on any of these? I will run the tests sometime tonight and let you know. No new significant failures have been found. (Some trivial issues have been reported in the bug tracker). -srid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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_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 two major problems with them:
1. It's easy to inadvertently convert them back to normal strings. If a
formatting API even calls "str" on the format string then we end up with
a problem (and switching to containment instead of inheritance doesn't
really help, since all objects implement __str__).
2. They don't help with APIs that expect a percent-formatted string and
do more with it than just pass it to str.__mod__ (e.g. inspecting it for
particular values such as '%(asctime)s')
Still, it's worth considering adding the three fmt_* classes to the
string module to see how far they can get us in adapting the formats for
different APIs.
Note that I don't think these concepts are fully baked yet, so we
shouldn't do anything in a hurry - and anything that does happen should
be via a PEP so we can flush out more issues.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
Scott Dial wrote: > Allow me to be naive for a moment and say, > is this not the point of rc1 but to catch bugs that should not be in the > final? For an x.y.0 rc I would usually agree with you, but for x.y.z (where z > 0), the intended situation is for there to be zero functional changes between the rc and the release. (This actually holds true for the final rc in x.y.0 release as well). It's unfortunate, but the imminent point release gets people's attention in a way that the original "there is going to be a point release around this date" never seems to. If the release managers didn't draw a line and said "no more bug fixes, even minor ones" then we'd never get point releases out even close to on time. This is particularly so for bugs that aren't a regression from x.y.(z-1) - it's most often regressions which are marked as release blockers rather than newly discovered (or analysed) bugs which have existed in the series since the x.y.0 release. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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) 1. It's easy to inadvertently convert them back to normal strings. If a formatting API even calls "str" on the format string then we end up with a problem (and switching to containment instead of inheritance doesn't really help, since all objects implement __str__). 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 do those things. 2. They don't help with APIs that expect a percent-formatted string and do more with it than just pass it to str.__mod__ (e.g. inspecting it for particular values such as '%(asctime)s') True, but I don't think there's many such cases in the first place, and such places can be fixed to not do that as they're found. Until they are fixed, fmt_braces will loudly fail when used with that API (assuming fmt_braces is not a subclass of str). James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 do those things. Actually, logging calls str() on the object passed as the first argument in a logging call such as logger.debug(), which can either be a format string or an arbitrary object whose __str__() returns the format string. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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, collections.Mapping):
> return self.__class__(self.format(**stuff))
> else:
> return self.__class__(self.format(stuff))
>
> The biggest issue is that ``"%s" % {'a': 42}`` substitutes the dict
> instead of throwing an error that str.format() would do with the code
> above. But what's nice about this is I think I can use this now w/ any
> library that expects % interpolation and it should basically work.
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 {}-format strings? Could someone
please lay it out for me, step by step, showing what happens in each
version?
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 two major problems with them:
>
> 1. It's easy to inadvertently convert them back to normal strings. If a
> formatting API even calls "str" on the format string then we end up with
> a problem (and switching to containment instead of inheritance doesn't
> really help, since all objects implement __str__).
>
> 2. They don't help with APIs that expect a percent-formatted string and
> do more with it than just pass it to str.__mod__ (e.g. inspecting it for
> particular values such as '%(asctime)s')
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 can look for '%(asctime)s',
'{asctime}' or '$asctime' according to the style.
Just to clarify - LogRecord.getMessage *will* call str() on a message object if
it's not a string or Unicode object. For 2.x the logic is
if type(msg) not in (unicode, str):
msg = str(msg)
and for 3.x the check is for isinstance(msg, str).
> Still, it's worth considering adding the three fmt_* classes to the
> string module to see how far they can get us in adapting the formats for
> different APIs.
>
> Note that I don't think these concepts are fully baked yet, so we
> shouldn't do anything in a hurry - and anything that does happen should
> be via a PEP so we can flush out more issues.
Yes, we're just "kicking the tires" on the various ideas. There are things still
a bit up in the air such as what happens when pickling and sending to an older
version of Python, etc. which still need to be resolved for logging, at least.
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
On Oct 1, 2009, at 5:48 PM, Sridhar Ratnakumar wrote: No new significant failures have been found. (Some trivial issues have been reported in the bug tracker). Fantastic, thanks. I'll be tagging the final release soon. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 can look for '%(asctime)s',
'{asctime}' or '$asctime' according to the style.
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, without parsing the format
string. Now that I think of it, the same technique could be used with
%-formatting:
import datetime
class DelayedStr:
def __init__(self, fn):
self.fn = fn
self.obj = None
def __str__(self):
if self.obj is None:
self.obj = self.fn()
return self.obj.__str__()
def current_time():
print "calculating time"
return datetime.datetime.now()
# will not compute current time
print '%(msg)s' % {'asctime':DelayedStr(current_time),
'msg':'test'}
# will compute current time: same dict used as before
print '%(asctime)s %(msg)s' % {'asctime':DelayedStr(current_time),
'msg':'test'}
Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 {}-format strings? Could someone
please lay it out for me, step by step, showing what happens in each
version?
Here's what I said in my first message, suggesting this change.
Copy&pasted below:
I wrote:
1) introduce the above feature, and recommend in docs that people
only ever use new-style format strings, wrapping the string in
newstyle_formatstr() when necessary for passing to an API which uses
% internally.
2) A long time later...deprecate str.__mod__; don't deprecate
newstyle_formatstr.__mod__.
3) A while after that (maybe), remove str.__mod__ and replace all
calls in Python to % (used as a formatting operator) with .format()
so that the default is to use newstyle format strings for all APIs
from then on.
So do (1) in 3.2. Then do (2) in 3.4, and (3) in 3.6. I skipped two
versions each time because of how widely this API is used, and the
likely pain that doing the transition quickly would cause. But I guess
you *could* do it in one version each step.
James
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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.
>
> 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.
I agree. I view them more as a band-aid over APIs that only accept %
formatting but the user of the library wants to use {} formatting.
> (Naming
> the three major string formatting techniques by the key symbols involved
> is a really good idea though)
>
> The two major problems with them:
>
> 1. It's easy to inadvertently convert them back to normal strings. If a
> formatting API even calls "str" on the format string then we end up with
> a problem (and switching to containment instead of inheritance doesn't
> really help, since all objects implement __str__).
>
Well, you can override the methods on str to always return the proper
thing, e.g. ``def __str__(self): return self``. Do the same for
__add__() and all other methods on strings that return a string
themselves. It should be possible to prevent Python code from
stripping off the class.
> 2. They don't help with APIs that expect a percent-formatted string and
> do more with it than just pass it to str.__mod__ (e.g. inspecting it for
> particular values such as '%(asctime)s')
>
Nope, they don't and people would need to be warned against this.
> Still, it's worth considering adding the three fmt_* classes to the
> string module to see how far they can get us in adapting the formats for
> different APIs.
>
> Note that I don't think these concepts are fully baked yet, so we
> shouldn't do anything in a hurry - and anything that does happen should
> be via a PEP so we can flush out more issues.
Having a PEP that lays out how we think people should consider
transitioning their code would be good.
-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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.__class__(self.format(*stuff))
>>> elif isinstance(stuff, collections.Mapping):
>>> return self.__class__(self.format(**stuff))
>>> else:
>>> return self.__class__(self.format(stuff))
>>>
>>> The biggest issue is that ``"%s" % {'a': 42}`` substitutes the dict
>>> instead of throwing an error that str.format() would do with the code
>>> above. But what's nice about this is I think I can use this now w/ any
>>> library that expects % interpolation and it should basically work.
>>
>> Could someone please lay it out for me, step by step, showing what
>> happens in each version?
>
> 1. Nothing changes as hopefully the wrapper works fine (as people are
> pointing out, though, my approach needs to override __str__() to
> return 'self', else the str type will just return what it has
> internally in its buffer).
>
> 2. Raise a deprecation warning when ``isinstance(ob, brace_fmt)`` is
> false. When a class is passed in that is a subclass of brace_fmt, call
> ob.format() on it.
>
> 3. Require the subclass.
>
> 4. Remove the requirement and always call ob.format().
Thanks Brett, that's clear. So you save one version over the proposal
of adding a format= flag to the API.
On Thu, Oct 1, 2009 at 4:13 PM, James Y Knight wrote:
> Here's what I said in my first message, suggesting this change. Copy&pasted
> below:
[snip steps that only talk about str.__mod__, not an API that uses it]
I didn't understand how you wanted to apply your suggestion to an API
(instead of str.__mod__) the first time and I still don't understand
it. Is what Brett has proposed the same thing?
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?
I found this hg's issue. http://mercurial.selenic.com/bts/msg8375 I think below fix is not enabled on Mac OS X. http://svn.python.org/view/python/trunk/Include/pyport.h?view=diff&pathrev=43219&r1=36792&r2=36793 I can't confirm it because I am not Mac OS X user. Can anyone confirm it? -- Naoki INADA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 mileage? What do y'all think?
What about the proposal I made earlier?
(support for giving a callable, so that you pass the "{foobar}".format method
when you want new-style formatting)
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 class idea being bandied about. This would be scarcely worse
than passing the string itself.
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
