Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-07-06 Thread Ben Wolfson
FWIW, new patches have been attached to the bug report (http://bugs.python.org/issue12014), one of which is intended to bring behavior in line with the documentation, and the other of which is intended to implement Greg Ewing's proposal to allow only identifiers (or integers) in the arg_name, attri

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-13 Thread Ben Wolfson
On Mon, Jun 13, 2011 at 5:36 PM, Greg Ewing wrote: > Ben Wolfson wrote: > >> If by "item selector" you mean (using the names from the grammar in >> the docs) the element_index, I don't see why this should be the case; >> dictionaries can contain non-identified keys, after all. > > Of course they c

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-13 Thread Greg Ewing
Ben Wolfson wrote: If by "item selector" you mean (using the names from the grammar in the docs) the element_index, I don't see why this should be the case; dictionaries can contain non-identified keys, after all. Of course they can, but that's not the point. The point is that putting arbitrar

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-13 Thread Ben Wolfson
On Sat, Jun 11, 2011 at 4:29 PM, Greg Ewing wrote: > 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 dou

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-11 Thread Greg Ewing
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

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-11 Thread Terry Reedy
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

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-11 Thread Ben Wolfson
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

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-11 Thread Petri Lehtinen
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

Re: [Python-Dev] PEP 3101 implementation vs. documentation

2011-06-11 Thread Nick Coghlan
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

[Python-Dev] PEP 3101 implementation vs. documentation

2011-06-10 Thread Ben Wolfson
Hello, I'm writing because discussion in a bug report I submitted () has suggested that, insofar as at least part of the issue revolves around the interpretation of PEP 3101, that aspect belonged on python-dev. In particular, I was told that the PEP, not the docu