"as" keyword woes
benjamin.kaplan at case.edu
Wed Dec 10 20:57:23 CET 2008
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
> >>>>> some words which would normally be identifiers have a special meaning
> >>>>> in
> >>>>> certain contexts, but the syntax precludes any ambiguity, and not in
> >>>>> 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
> > they are parsed you need to look at only the next word. If you're about
> > 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
> > statement (OK, you don't know exactly what kind of statement it is at
> > 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
> > 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
> > ambiguity, but it's the only such word in the language, so it's just
> > 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?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list