the annoying, verbose self

[Kay Schluehr]

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