Antoine Pitrou <solipsis <at> 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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to