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
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 I
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
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
_
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
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
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
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 th
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 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 relea
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
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 n
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
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
> > tho
[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
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)
>
> _
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
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 o
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.
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 int
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):
s
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 whe
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
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 yo
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 redir
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 th
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,
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 a
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
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 {}"),
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.Templa
44 matches
Mail list logo
