[Python-checkins] r42611 - python/trunk/Python/ast.c

Guido van Rossum guido at python.org
Tue Feb 28 17:52:28 CET 2006


Ah! That's very old language, probably dating back from when you could
only have a single short slice OR an exprlist. The ambiguity, if there
is one, is at the level of "which code do we generate". That is
decided in favor of a tuple if there's at least one comma at the top
level; in favor of a single slice() object if there are no commas but
two colons; in favor of a SLICE operation if there's exactly one
colon; and in favor of a single expression if there are neither colons
nor commas. When there are both colons and commas, the comma has lower
precedence as the colon, and e.g. x[a:b,c] is equivalent to
x[(slice(a,b), c)].

In Python 3000 I want to get rid of the SLICE operations, so that
x[a:b] === x[slice(a,b)]. The SLICE API has several problems: it only
allows integers, and interprets negative indices rather than letting
the object do that. __getitem__ and slice() don't have any of those
problems.

(CC'ing Nick and Raymond since this needs to be updated in the
reference manual.)

--Guido

On 2/27/06, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
> I'm referring to the ambiguity noted in the language reference.
>
> http://docs.python.org/ref/slicings.html
>
> "There is ambiguity in the formal syntax here: anything that looks
> like an expression list also looks like a slice list, so any
> subscription can be interpreted as a slicing. Rather than further
> complicating the syntax, this is disambiguated by defining that in
> this case the interpretation as a subscription takes priority over the
> interpretation as a slicing (this is the case if the slice list
> contains no proper slice nor ellipses). Similarly, when the slice list
> has exactly one short slice and no trailing comma, the interpretation
> as a simple slicing takes priority over that as an extended slicing."
>
> Jeremy
>
> On 2/27/06, Guido van Rossum <guido at python.org> wrote:
> > On 2/27/06, jeremy.hylton <python-checkins at python.org> wrote:
> > > Author: jeremy.hylton
> > > Date: Mon Feb 27 18:29:29 2006
> > > New Revision: 42611
> > >
> > > Modified:
> > >    python/trunk/Python/ast.c
> > > Log:
> > > Fix parsing of subscriptlist.
> > >
> > > (Armin's SF bug report).
> > > d = {}
> > > d[1,] = 1
> > > Now handled correctly
> > [...]
> > > +            /* The grammar is ambiguous here. The ambiguity is resolved
> > > +               by treating the sequence as a tuple literal if there are
> > > +               no slice features.
> > > +            */
> >
> > The grammar is not ambiguous. I don't understand the AST code well
> > enough where the problem is/was, but there is no ambiguity in the
> > parse tree.
> >
> > --
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> > _______________________________________________
> > Python-checkins mailing list
> > Python-checkins at python.org
> > http://mail.python.org/mailman/listinfo/python-checkins
> >
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-checkins mailing list