Eric Smith wrote:
> Ron Adam wrote:
>>
>>
>> Eric Smith wrote:
>>> Ron Adam wrote:
> get_field(field_name, args, kwargs, used_args)
> Given a field_name as returned by parse, convert it to an object to
> be formatted. The default version takes strings of the form
> defined in t
Eric Smith wrote:
> Ron Adam wrote:
>> I wonder if this is splitting things up a bit too finely? If the format
>> function takes a conversion argument, it makes it possible to do
>> everything by overriding format_field.
>>
>> def format_field(self, value, format_spec, conversion):
>>
Ron Adam wrote:
>
>
> Eric Smith wrote:
>> Ron Adam wrote:
get_field(field_name, args, kwargs, used_args)
Given a field_name as returned by parse, convert it to an object to
be formatted. The default version takes strings of the form defined
in the PEP, such as "0[name]" or
Eric Smith wrote:
> Ron Adam wrote:
>>> get_field(field_name, args, kwargs, used_args)
>>> Given a field_name as returned by parse, convert it to an object to
>>> be formatted. The default version takes strings of the form defined
>>> in the PEP, such as "0[name]" or "label.title". It records
Ron Adam wrote:
>> get_field(field_name, args, kwargs, used_args)
>> Given a field_name as returned by parse, convert it to an object to be
>> formatted. The default version takes strings of the form defined in
>> the PEP, such as "0[name]" or "label.title". It records which args
>> have been
Eric Smith wrote:
> One of the things that PEP 3101 deliberately under specifies is the
> Formatter class, leaving decisions up to the implementation. Now that a
> working implementation exists, I think it's reasonable to tighten it up.
>
> I have checked in a Formatter class that specifies t
Talin wrote:
> Eric Smith wrote:
>> Eric Smith wrote:
>>> Jim Jewett wrote:
>>
but you might want to take inspiration from the "tail" of an
elementtree node, and return the field with the literal next to it as
a single object.
(literal_text, field_name, format_spec, con
Eric Smith wrote:
> Eric Smith wrote:
>> Jim Jewett wrote:
>
>>> but you might want to take inspiration from the "tail" of an
>>> elementtree node, and return the field with the literal next to it as
>>> a single object.
>>>
>>> (literal_text, field_name, format_spec, conversion)
>> I think I
Eric Smith wrote:
> Jim Jewett wrote:
>> but you might want to take inspiration from the "tail" of an
>> elementtree node, and return the field with the literal next to it as
>> a single object.
>>
>> (literal_text, field_name, format_spec, conversion)
>
> I think I like that best.
I impleme
Jim Jewett wrote:
> On 8/28/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> parse(format_string)
>
>> ... returns an iterable of tuples
>> (literal_text, field_name, format_spec, conversion)
>
> Which are really either
>
> (literal_text, None, None, None)
> or
> (None, field_name, format_sp
On 8/28/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> parse(format_string)
>... returns an iterable of tuples
> (literal_text, field_name, format_spec, conversion)
Which are really either
(literal_text, None, None, None)
or
(None, field_name, format_spec, conversion)
I can't help thinking
Eric Smith wrote:
> One of the things that PEP 3101 deliberately under specifies is the
> Formatter class, leaving decisions up to the implementation. Now that a
> working implementation exists, I think it's reasonable to tighten it up.
I should also have included the recipe for the 'smart' f
One of the things that PEP 3101 deliberately under specifies is the
Formatter class, leaving decisions up to the implementation. Now that a
working implementation exists, I think it's reasonable to tighten it up.
I have checked in a Formatter class that specifies the following methods
(in addi
13 matches
Mail list logo
