Ben Wolfson wrote:
You can't have an internal replacement
field in this part of the replacement field, so '{' can always safely
be assumed to be Just a Brace and not the start of a replacement
field, regardless of whether it's doubled,
I'm worried that the rules in this area are getting too
com
On 6/11/2011 6:32 AM, Petri Lehtinen wrote:
Nick Coghlan wrote:
[snip]
It seems to me that the intent of the pep and the current doc is that
field_names should match what one would write in code except that quotes
are left off of literal string keys. Which is to say, the brackets []
serve as
2011/6/11 Terry Reedy :
>
>> +What's New in Python 3.1.5?
>> +===
>> +
>> +*Release date: -XX-XX*
>> +
>> +Core and Builtins
>> +-
>> +
>> +Library
>> +---
>> +
>> +
>
> I presume that only security patches should be added.
Indeed.
--
Regards,
Ben
On Sat, Jun 11, 2011 at 2:16 AM, Nick Coghlan wrote:
> On Sat, Jun 11, 2011 at 7:15 AM, Ben Wolfson wrote:
> To summarise (after both the above post and the discussion on the tracker)
Thanks for the summary!
>
> That would leave us with the following set of rules for name fields:
>
> 1. Numeric
Nick Coghlan wrote:
[snip]
> The rules for name fields would then become:
>
> 1. Numeric fields start with a digit and are terminated by any
> non-numeric character.
>
> 2. An identifier name field is terminated by any one of:
> '}' (terminates the replacement field)
> '!' (terminates ide
On Sat, Jun 11, 2011 at 7:15 AM, Ben Wolfson wrote:
[snip very thorough analysis]
To summarise (after both the above post and the discussion on the tracker)
The current str.format implementation differs from the documentation
in two ways:
1. It ignores the presence of an unclosed index field wh
Le 11/06/2011 02:41, R. David Murray a écrit :
I haven't read through your post, but if you don't know about it I
suspect that you will be interested in the following:
http://code.activestate.com/pypm/pysandbox/
I'm pretty sure Victor will be happy to have someone else interested in
this t
