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
--
http://mail.python.org/mailman/listinfo/python-list
