Eric Smith wrote:
> Ron Adam wrote:
>>
>>
>> Eric Smith wrote:
>>> Ron Adam wrote:
> I've been re-reading the PEP, in an effort to make sure everything
> is working. I realized that these tests should not pass. The PEP
> says that "Format specifiers can themselves contain replacem
On Wed, 22 Aug 2007 23:15:56 -0400
Andrew James Wade <[EMAIL PROTECTED]> wrote:
> And I'd do
> the recursive substitution before even starting to parse the field:
> it's simple and powerful.
Scratch that suggestion; the implications need to be thought through.
If we allow recursive substitution o
On Wed, 22 Aug 2007 21:33:19 -0400
Eric Smith <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
...
> > That would mean there is no way to pass a brace to a __format__ method.
>
> No way using string.format, correct. You could pass it in using the
> builtin format(), or by calling __format__ directl
Ron Adam wrote:
>
>
> Eric Smith wrote:
>> Ron Adam wrote:
I've been re-reading the PEP, in an effort to make sure everything
is working. I realized that these tests should not pass. The PEP
says that "Format specifiers can themselves contain replacement
fields". The tes
Eric Smith wrote:
> Ron Adam wrote:
>>> I've been re-reading the PEP, in an effort to make sure everything is
>>> working. I realized that these tests should not pass. The PEP says
>>> that "Format specifiers can themselves contain replacement fields".
>>> The tests above have replacement f
Ron Adam wrote:
>> I've been re-reading the PEP, in an effort to make sure everything is
>> working. I realized that these tests should not pass. The PEP says
>> that "Format specifiers can themselves contain replacement fields".
>> The tests above have replacement fields in the field name, w
Guido van Rossum wrote:
> On 8/22/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> James Thiele wrote:
>>> In the section "Explicit Conversion Flag" of PEP 3101 it says:
>>>
>>> Currently, two explicit conversion flags are recognized:
>>>
>>> !r - convert the value to a string using repr().
>>>
On 8/22/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> James Thiele wrote:
> > In the section "Explicit Conversion Flag" of PEP 3101 it says:
> >
> > Currently, two explicit conversion flags are recognized:
> >
> > !r - convert the value to a string using repr().
> > !s - convert the v
James Thiele wrote:
> In the section "Explicit Conversion Flag" of PEP 3101 it says:
>
> Currently, two explicit conversion flags are recognized:
>
> !r - convert the value to a string using repr().
> !s - convert the value to a string using str().
> --
> It does not say what acti
In the section "Explicit Conversion Flag" of PEP 3101 it says:
Currently, two explicit conversion flags are recognized:
!r - convert the value to a string using repr().
!s - convert the value to a string using str().
--
It does not say what action is taken if an unrecognized expli
Eric Smith wrote:
> Eric Smith wrote:
>> Talin wrote:
>>> A new version is up, incorporating material from the various discussions
>>> on this list:
>>>
>>> http://www.python.org/dev/peps/pep-3101/
>> self.assertEquals('{0[{1}]}'.format('abcdefg', 4), 'e')
>> self.assertEquals('{foo[{bar}]}'
Eric Smith wrote:
> Talin wrote:
>> A new version is up, incorporating material from the various discussions
>> on this list:
>>
>> http://www.python.org/dev/peps/pep-3101/
>
> self.assertEquals('{0[{1}]}'.format('abcdefg', 4), 'e')
> self.assertEquals('{foo[{bar}]}'.format(foo='abcdefg', ba
Talin wrote:
> Eric Smith wrote:
>> James Thiele wrote:
>>> I think the example:
>>>
>>> "My name is {0.name}".format(file('out.txt'))
> Those examples are kind of contrived to begin with. Maybe we should
> replace them with more realistic ones.
I just added this test case:
d = dat
On 8/16/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > Alex Holkner wrote:
> >> What is the behaviour of whitespace in a format specifier? e.g.
> >> how much of the following is valid?
> >>
> >> "{ foo . name : 20s }".format(foo=open('bar'))
> >
> > Eric, it's your call :)
>
Talin wrote:
> Alex Holkner wrote:
>> What is the behaviour of whitespace in a format specifier? e.g.
>> how much of the following is valid?
>>
>> "{ foo . name : 20s }".format(foo=open('bar'))
>
> Eric, it's your call :)
I'm okay with whitespace before the colon (or !, as the case may b
Alex Holkner wrote:
> Talin wrote:
>> A new version is up, incorporating material from the various discussions
>> on this list:
>>
>> http://www.python.org/dev/peps/pep-3101/
>
> I've been following this thread for a few weeks, and I believe the
> following issues haven't yet been addressed
Talin wrote:
> A new version is up, incorporating material from the various discussions
> on this list:
>
> http://www.python.org/dev/peps/pep-3101/
I've been following this thread for a few weeks, and I believe the
following issues haven't yet been addressed:
The PEP abstract says this
Talin wrote:
> Eric Smith wrote:
>> Talin wrote:
>>> Guido expressed a definite preference for having them be first.
>>
>> I was afraid of that. Then can we say they'll always go first? Or is
>> the intent really to say they can go anywhere (PEP says "typically
>> placed")?
>
> I can revise it
Eric Smith wrote:
> Talin wrote:
>> Eric Smith wrote:
>>> James Thiele wrote:
The section on the explicit conversion flag contains the following
line:
These flags are typically placed before the format specifier:
Where else can they be placed?
>>>
>>> I'd like t
Talin wrote:
> Eric Smith wrote:
>> James Thiele wrote:
>>> The section on the explicit conversion flag contains the following line:
>>>
>>> These flags are typically placed before the format specifier:
>>>
>>> Where else can they be placed?
>>
>> I'd like this to say they can only be placed
Eric Smith wrote:
> James Thiele wrote:
>> The section on the explicit conversion flag contains the following line:
>>
>> These flags are typically placed before the format specifier:
>>
>> Where else can they be placed?
>
> I'd like this to say they can only be placed where the PEP describe
Eric Smith wrote:
> James Thiele wrote:
>> I think the example:
>>
>> "My name is {0.name}".format(file('out.txt'))
>>
>> Would be easier to understand if you added:
>>
>> Which would produce:
>>
>> "My name is 'out.txt'"
>
> I agree.
>
> Also, the example a couple of paragraphs down:
James Thiele wrote:
> The section on the explicit conversion flag contains the following line:
>
> These flags are typically placed before the format specifier:
>
> Where else can they be placed?
I'd like this to say they can only be placed where the PEP describes
them, or maybe to be onl
James Thiele wrote:
> I think the example:
>
> "My name is {0.name}".format(file('out.txt'))
>
> Would be easier to understand if you added:
>
> Which would produce:
>
> "My name is 'out.txt'"
I agree.
Also, the example a couple of paragraphs down:
"My name is {0[name]}".format(di
The section on the explicit conversion flag contains the following line:
These flags are typically placed before the format specifier:
Where else can they be placed?
Also there is no description of what action (if any) is taken if an
unknown explicit conversion flag is encoubtered.
On 8/1
I think the example:
"My name is {0.name}".format(file('out.txt'))
Would be easier to understand if you added:
Which would produce:
"My name is 'out.txt'"
On 8/14/07, Talin <[EMAIL PROTECTED]> wrote:
> A new version is up, incorporating material from the various discussions
> on
Talin wrote:
> A new version is up, incorporating material from the various discussions
> on this list:
>
> http://www.python.org/dev/peps/pep-3101/
I have a number of parts of this implemented. I'm refactoring the
original PEP 3101 sandbox code to get it working. Mostly it involves
un
A new version is up, incorporating material from the various discussions
on this list:
http://www.python.org/dev/peps/pep-3101/
Diffs are here:
http://svn.python.org/view/peps/trunk/pep-3101.txt?rev=57044&r1=56535&r2=57044
-- Talin
___
Python
28 matches
Mail list logo
