An alternative approach to bound methods

[Tim Couper]

Marcin

As I said before (IMHO) you are addressing something
important here, which seems to be self-evident to your
good self, but needs to be clearly understood by
others. Being a simple soul, I wonder if it might be
possible to restate the proposal again, maybe in a
top-down manner. Here's where I'm at, as they say.

Would I be right in saying that an objective (or is it
a consequence?) of the proposal is to permit
Pythonesque class methods as well as class attributes
in Python? If so, does the "this-is-what-I-would-like"
example which I gave in a previous email demonstrate
the requirement correctly?

This could then lead into a presentation again of the
changes that would be needed to make Python operate in
this way, and then the implications of such changes.
Again I think you see all these clearly (and they are
maybe obvious to you and others!)

It would appear that the changes covered by the
proposal are more far-reacing than the introduction of
class methods; it would be good to understand this
scope, the further benefits and downsides. Having the
class methods illustration to hand would I think be a
good stepping stone to what seems to be a more general
case.

If this is an inappropriate suggestion, please say so,
I realise it could be just me that is a bit slow :-)

Tim
  


> 
> > Where do you read/infer the limitation to *class*
> methods?
> 
> My proposal doesn't change how instance methods and
> instance attributes
> can be used. Only class attributes change.
> 
> Or I didn't understand what you mean?
> 
> > But how does a given function, whose def is inside
> a class, know
> > whether it's supposed to recurse through its
> (potential) overrider
> > (via a same-name method of the first argument) or
> by defeating the
> > override (via its bare name, or, equivalently if
> your proposal was
> > adopted, using itself as an attribute in its
> enclosing class)?
> 
> Are you asking what should one choose when he is
> writing the class?
> I don't know any case where it should recurse
> through its potential
> overrider yet, but perhaps they exist. This question
> can't have a
> general answer, similarly as questions like 'which
> class should I
> make an instance of here'.
> 
> Are you asking about the semantics of a particular
> piece of code?
> If so, which code? My proposal is unambiguous.
> 
> > Recursion apart, what distinguishes, e.g., a
> method foo in class
> > Derived(Base), calling the version it overrides as
> Base.foo(self,x,y),
> > and a "class-method" bar calling the same-name
> class-method of
> > the base class as Base.bar(x,y,z)?
> 
> Technically nothing.
> 
> Ideologically foo is an instance method, and bar is
> a class method,
> i.e. the first argument of foo is supposed to be an
> instance of a
> subclass of Base (even Derived at this usage point).
> 
> Instance methods are special cases of class methods,
> where the
> first argument is an object of the class we are in.
> They are not
> distinguished by declaration: a method can play the
> role of both.
> 
> We have a shortcut for calling instance methods:
> instead of
>     obj.__class__.method (obj, arg1, arg2)
> you can also write
>     obj.method (arg1, arg2)
> 
> It happens at the time of accessing methods from the
> instance, i.e.
>     obj.method
> itself means
>     lambda *args, **kwargs: obj.__class__.method
> (obj, *args, **kwargs)
> when type (obj) == types.InstanceType
>          and not obj.__dict__.has_key ('method').
> 
> That's it.
> 
> -- 
>  __("<  Marcin Kowalczyk * qrczak at knm.org.pl
> http://qrczak.ids.net.pl/
>  \__/
>   ^^                      SYGNATURA ZASTÊPCZA
> QRCZAK
> 
> 
> > -- 
> http://mail.python.org/mailman/listinfo/python-list
> 


____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie