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
On Sat, Jun 11, 2011 at 7:15 AM, Ben Wolfson wolf...@gmail.com 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
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 identifier
On Sat, Jun 11, 2011 at 2:16 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jun 11, 2011 at 7:15 AM, Ben Wolfson wolf...@gmail.com 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
2011/6/11 Terry Reedy tjre...@udel.edu:
+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,
Benjamin
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
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
