On Wed, Dec 10, 2008 at 12:22 PM, Patrick Mullen <[EMAIL PROTECTED]>wrote:
> On Wed, Dec 10, 2008 at 6:57 AM, MRAB <[EMAIL PROTECTED]> wrote: > > Aaron Brady wrote: > >> > >> On Dec 9, 12:40 pm, MRAB <[EMAIL PROTECTED]> wrote: > >>> > >>> Aaron Brady wrote: > >>>> > >>>> On Dec 9, 8:28 am, MRAB <[EMAIL PROTECTED]> 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 >
-- http://mail.python.org/mailman/listinfo/python-list
