the annoying, verbose self

[Colin J. Williams]

Kay Schluehr wrote:
> Colin J. Williams schrieb:
>> Kay Schluehr wrote:
>>> On Nov 22, 8:43 pm, Bruno Desthuilliers
>>> <bdesth.quelquech... at free.quelquepart.fr> wrote:
>>>> Colin J. Williams a écrit :
>>>>
>>>>
>>>>
>>>>> bearophileH... at lycos.com 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.
>
>