Olemis Lang gmail.com> writes:
>
> > For some people, use of {} over % is more about personal taste than about
> > the
> > actual usage of str.format's flexibility;
>
> Thought you were talking about me, you only needed to say «he has
> black hair and blue eyes» ... ;o)
>
No, it was a genera
On Sun, Oct 31, 2010 at 9:55 AM, Vinay Sajip wrote:
> Olemis Lang gmail.com> writes:
>>
>> On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw python.org> wrote:
>> > I haven't played with it yet, but do you think it makes sense to add a
>> > 'style' keyword argument to basicConfig()? That would mak
On Sun, 31 Oct 2010 14:55:34 -, Vinay Sajip wrote:
> Olemis Lang gmail.com> writes:
> > On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw python.org>
> > wrote:
> > > I haven't played with it yet, but do you think it makes sense to add a
> > > 'style' keyword argument to basicConfig()? Â That
Olemis Lang gmail.com> writes:
>
> On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw python.org> wrote:
> > I haven't played with it yet, but do you think it makes sense to add a
> > 'style' keyword argument to basicConfig()? That would make it pretty easy
> > to get the formatting style you want
Eric Smith trueblade.com> writes:
> I keep meaning to review this but haven't had time. One thing I want to
> look at specifically is the ability to put the time formatting into the
> str.format version of the format string. Now that the time format
> specifier can be included in the format st
On 10/26/10 7:08 AM, Nick Coghlan wrote:
On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote:
Comments welcome. Assuming there are no strong objections asking for reversion
of this change, I'll publicise to the wider community in a few days.
It strikes me as a solid, pragmatic solution to a t
On Fri, Oct 29, 2010 at 10:07 AM, Barry Warsaw wrote:
> On Oct 25, 2010, at 02:28 PM, Vinay Sajip wrote:
>
>>I've just checked in a change to logging into the py3k branch (r85835),
>>including doc changes and tests, for providing slightly more flexibility in
>>alternative format styles for logging
On Tue, Oct 26, 2010 at 6:15 AM, Nick Coghlan wrote:
> On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote:
>> On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip
>> wrote:
>>> Comments welcome. Assuming there are no strong objections asking for
>>> reversion
>>> of this change, I'll publicise to th
On Oct 25, 2010, at 02:28 PM, Vinay Sajip wrote:
>I've just checked in a change to logging into the py3k branch (r85835),
>including doc changes and tests, for providing slightly more flexibility in
>alternative format styles for logging.
>
>Basically, Formatter.__init__ gets an extra optional key
Nick Coghlan gmail.com> writes:
> Looking at your checkin though, I wonder if it might be worth
> implementing some little formatting style classes to get rid of the
> if/elif chains from the Formatter code. Something like:
Fair comment: I did think about the messiness of that if/elif, but consid
Line 31 (in Pastebin): _STYLE_CODES = tuple("% { $".split())
Is this really necessary? Why not
_STYLE_CODES = ('%', '{', '$')
On Tue, Oct 26, 2010 at 1:15 PM, Nick Coghlan wrote:
> On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote:
> > On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip
> wrote:
On Tue, Oct 26, 2010 at 9:08 PM, Nick Coghlan wrote:
> On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote:
>> Comments welcome. Assuming there are no strong objections asking for
>> reversion
>> of this change, I'll publicise to the wider community in a few days.
>
> It strikes me as a solid, p
On Tue, Oct 26, 2010 at 12:28 AM, Vinay Sajip wrote:
> Comments welcome. Assuming there are no strong objections asking for reversion
> of this change, I'll publicise to the wider community in a few days.
It strikes me as a solid, pragmatic solution to a thorny problem.
Looking at your checkin t
13 matches
Mail list logo
