Idea about method parameters

Wolfgang Grafen wolfgang.grafen at gmx.de
Fri Sep 28 00:07:17 CEST 2001


Attempt 3:

>>> class A:
...     def __init__(self,a,b,c=333,d=444):
...         e = d + c
...         del c,d
...         self.__dict__.update(vars())  # save a,b,e
...         del self.__dict__['self']     # remove cyclic self reference
...     def __call__(self):
...         print self.a,self.b,self.e
...
>>> a=A(1,2)
>>> a()
1 2 777

2.  Accessing self.__dict__ is *not hackish at all*.
    - It is documented in the Python language reference
    - If you issue following command in the python2.1 directory
             grep -il __dict__ *\.py | wc -l
      you will find out that 21 out of 158 modules use this construct!

6.  It also works for a subset of the parameters :)

Well, let's finish this discussion here. With the construct above you
have everything you requested for. Your suggestion to adapt the
interpreter to also accept "self." as a prefix for the the variables in
the parameter list
might give you *your* individual convinience syntax. Besides that nobody
missed this feature for years. A working interpreter has to be modified
for
this minor or better said, irregular syntax as already Eric Max Francis
pointed out in his answer. Then there will be a difference between class
and
function parameter list handling. Checking for self is not enough but you
have
to check for the first name and it's occurence as a prefix in the
parameter list. self is used by convention. But any valid name will have
to work as
well. And don't forget that tests have to be written. And forget the
beautiful
small BNF of Python. And end soon with something similar to Perl.

But now to the *killer argument against your suggestion*:
Allowing self.<variable_name> in the interfaces describes already an
implementation detail which heavily violates object orientated coding
rules.
Not only this, <variable_name> will be the same as self.<variable_name>.
x=NewClass(self.a=12,self.b=45) would be the same as x=NewClass(a=12,b=45)

unless you invent further restrictions...

And in the real end:
Changes for Python take a lot of effort. Write a PEP, discuss your
proposal
for at least half a year, persuade at least 50% of the active Python
community and pray that Guido can accept it. This procedure assures
Python's
quality :)

Wolfgang




More information about the Python-list mailing list