"as" keyword woes

[Benjamin Kaplan]

On Wed, Dec 10, 2008 at 12:22 PM, Patrick Mullen <saluk64007 at gmail.com>wrote:

> On Wed, Dec 10, 2008 at 6:57 AM, MRAB <google at mrabarnett.plus.com> wrote:
> > Aaron Brady wrote:
> >>
> >> On Dec 9, 12:40 pm, MRAB <goo... at mrabarnett.plus.com> wrote:
> >>>
> >>> Aaron Brady wrote:
> >>>>
> >>>> On Dec 9, 8:28 am, MRAB <goo... at mrabarnett.plus.com> wrote:
> >>>> snip
> >>>>>
> >>>>> In some languages (I think Delphi is one of them - it's been a
> while!)
> >>>>> some words which would normally be identifiers have a special meaning
> >>>>> in
> >>>>> certain contexts, but the syntax precludes any ambiguity, and not in
> a
> >>>>> difficult way. "as" in Python was one of those.
> >>>>> I certainly wouldn't want something like PL/I, where "IF", "THEN" and
> >>>>> "ELSE" could be identifiers, so you could have code like:
> >>>>>     IF IF = THEN THEN
> >>>>>         THEN = ELSE;
> >>>>>     ELSE
> >>>>>         ELSE = IF;
> >>>>> Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language)<http://en.wikipedia.org/wiki/PL/I_%28programming_language%29>
> .
> >>>>
> >>>> snip
> >>>> That is, 'certainly' doesn't change the meaning of your statement
> >>>> any.  You wouldn't want it, but King George III didn't want the
> >>>> American Revolution.
> >>>
> >>> It's called emphasis.
> >>
> >> I just take you to have meant, then, +1 on excluding keywords from
> >> identifiers.  You said it the long way though, so I thought I missed
> >> something deeper, that didn't come across.
> >>
> > IIRC, most computer languages have an LL(1) grammar, which means that
> when
> > they are parsed you need to look at only the next word. If you're about
> to
> > parse a statement and the next word is "IF" then you know it's an
> > IF-statement, if it's an identifier then it's either a call or an
> assignment
> > statement (OK, you don't know exactly what kind of statement it is at
> that
> > point, but it works out just fine!).
> >
> > In the example from PL/I, "IF" could be the start of an IF-statement "IF
> > <condition> THEN" or an assignment statement "IF = <expression>". It's a
> bit
> > more tricky for the parser as well as the programmer.
> >
> > Life is easier if words having special meanings are reserved.
> >
> > However, that doesn't mean that all special words /must/ be reserved
> > (pragmatism beats purity). Sometimes the syntax makes it clear and
> > unambiguous, so you can get away with not making it a reserved word. The
> > word "as" in Python doesn't need to be reserved because the syntax
> precludes
> > ambiguity, but it's the only such word in the language, so it's just
> tidier
> > to make it reserved too.
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
> I don't have a huge stake in this, but I wouldn't mind a change to
> allow anything proceeding a "." or preceeding a "(" to not be
> identified as a keyword.  It is obvious to me a s a human reader that
> something.if is quite a bit different than just a bare if.  And as far
> as parsing technology goes, isn't it supposed to go for the biggest
> match first?  I would not be for allowing bare keywords to be used in
> the situations described above, but since we are so used to being able
> to being able to have say, myclass.dir() or myclass.len() without them
> overwriting the builtin functions, it makes sense to me to be able to
> define a myclass.as() or myclass.with() without overwriting the
> keywords.  Though I know the semantics behind these two things are
> very different, the rules I go through when reading the code are very
> similar.  The parser change might be a hassle, and it might not be
> worth it at all of course, but from a conceptual point of view it is
> simple.  I mean, even now you can do class.__dict__["as"].
>

so what happens here?

if(some_condition()) :
    do_something(a)

Yes, I know you don't need the parenthesis there in Python, but you still
can use it.


> I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword usage.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20081210/56a763c4/attachment-0001.html>