On Wed, Dec 10, 2008 at 11:57 AM, Benjamin Kaplan
<[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Dec 10, 2008 at 12:22 PM, Patrick Mullen <[EMAIL PROTECTED]>
> wrote:
>>
>> 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
>
>
Right, I now see how this scenario is tricky. It could maybe be in
the form of "<def> <keyword|identifier><colon>" but that starts
getting pretty complicated. Too tricky.
Following the period on the other hand still makes sense to me. It
makes sense in the nature of "I wouldn't mind seeing this added", but
I suppose it still might not make sense in the nature of "We should do
the work to make this a reality".
--
http://mail.python.org/mailman/listinfo/python-list
