Kay Schluehr wrote:
> Colin J. Williams schrieb:
>> Kay Schluehr wrote:
>>> On Nov 22, 8:43 pm, Bruno Desthuilliers
>>> <[EMAIL PROTECTED]> wrote:
>>>> Colin J. Williams a écrit :
>>>>
>>>>
>>>>
>>>>> [EMAIL PROTECTED] wrote:
>>>>>> Alexy:
>>>>>>> Sometimes I
>>>>>>> avoid OO just not to deal with its verbosity. In fact, I try to
>>>>>>> use
>>>>>>> Ruby anywhere speed is not crucial especially for @ prefix is
>>>>>>> better-
>>>>>>> looking than self.
>>>>>> Ruby speed will increase, don't worry, as more people will use it.
>>>>>> Bye,
>>>>>> bearophile
>>>>> I don't see this as a big deal, but suppose that the syntax were
>>>>> expanded so that, in a method, a dot ".", as a precursor to an
>>>>> identifier,
>>>>> was treated as "self." is currently treated?
>>>> <dead-horse-beaten-to-hell-and-back>
>>>>
>>>> Python's "methods" are thin wrapper around functions, created at
>>>> lookup
>>>> time (by the __get__ method of the function type). What you define
>>>> in a
>>>> class statement are plain functions, period. So there's just no way to
>>>> do what you're suggesting.
>>>>
>>>> </dead-horse-beaten-to-hell-and-back>
>>>
>>> The object model is irrelevant here. The substitution is purely
>>> syntactical and gets resolved at compile time:
>>>
>>> def foo(first, ...):
>>> .bar = ...
>>>
>>> is always equivalent with:
>>>
>>> def foo(first, ...):
>>> first.bar = ...
>>>
>>> and generates the same bytecode.
>>>
>>> Whether this is helpfull, beautifull or necessary is another issue.
>>>
>>> Kay
>>
>> I had never thought of trying the above, which is, essentially what I
>> was
>> suggesting, as the syntax specifies:
>>
>> primary ::=
>> atom | attributeref
>> | subscription | slicing | call
>>
>> attributeref ::=
>> primary "." identifier
>>
>> I did try it and get:
>>
>> # tmp.py
>> class Z():
>> def __init__(self):
>> a= 1
>> self.b= 2
>> #.c= 3 Marked as a syntax error by PyScripter
>>
>> def y(self):
>> self.a= 4
>> #.b= 5 Marked as a syntax error by PyScripter
>>
>> It seems that some, probably simple, change in the parsing is needed.
>>
>> Colin W.
>
> Sure. Since you cite the grammar let me say that I find it somewhat
> confusing that the grammar in the Python documentation doesn't
> correspond to the grammar used by the CPython parser. For the following
> I will use the notations of the Grammar file used by the CPython parser.
>
> In order to adapt the syntax take a look at
>
> atom: ('(' [yield_expr|testlist_gexp] ')' |
> '[' [listmaker] ']' |
> '{' [dictmaker] '}' |
> '`' testlist1 '`' |
> NAME | NUMBER | STRING+)
>
> The last row must be changed to
>
> ['.'] NAME | NUMBER | STRING+)
> ~~~~~
>
> But then you run into conflict with the definition of the ellipsis in
> rule
>
> subscript: '.' '.' '.' | test | [test] ':' [test] [sliceop]
>
> because you need two token of lookahead. Pythons LL(1) parser might not
> manage this.
>
> This problem vanishes with Python 3.0 which defines an own ellipsis
> literal:
>
> atom: ('(' [yield_expr|testlist_comp] ')' |
> '[' [testlist_comp] ']' |
> '{' [dictorsetmaker] '}' |
> NAME | NUMBER | STRING+ | '...' | 'None' | 'True' | 'False')
>
> Kay
>
Many thanks for this clarification. I hope that those beavering away on
Python 3000 will give further consideration to this matter.
Colin W.
>
>
--
http://mail.python.org/mailman/listinfo/python-list
