An alternative approach to bound methods

Marcin 'Qrczak' Kowalczyk qrczak at
Wed Feb 21 17:43:20 EST 2001

Tue, 20 Feb 2001 12:11:16 -0500 (EST), Jeremy Hylton <jeremy at> pisze:

> The ability to access class attributes via self is pretty fundamental
> property of Python.  I don't expect it will go away.

It's a pity.

With my proposal it could be at most retained as a compatibility hack:
when translating the object attribute access to class attribute access,
check if it's callable, and do the self-prepending transformation
only if it is - because it would be meaningless otherwise anyway.

But it does not fit the spirit of the proposal at all, it's bad to
rely on absence of an interface, and thus it would be deprecated.
No way to have it as a preferred access. You can refer to these names
unqualified, or qualified by self.__class__, or qualified by the class
name (each way has a slightly different semantics wrt. inheritance
and name rebinding), but not with self. Unless you copy them to
instances in __init__ (class attributes already can't be assigned to
from methods, so it should work in all cases).

Current Python does rely on a negative constraint: class attributes
can be any types *except* functions. This is bad in principle, even
if mostly harmless in practice. It's not quite harmless today: we
don't have class methods because of this, even though it's obvious
how they would be written if they worked, and they can be simulated
by other callable objects. It's also ugly that the builtin function
type has special rights that no other type can emulate.

Sorry, this proposal does change a fundamental Python's rule.
I believe it would be a saner design ignoring the status quo.
But it's difficult to apply it to an existing language without
breaking compatibility.

I can specify the details, write a PEP, write open questions about
the details, write examples etc., but for all that to make sense,
I would have to hear positive feedback from a person which can decide
about changing such core things.

> Also note that nested scopes do not allow access to class attributes
> as unqualified names.  When resolving free variables, class scopes are
> skipped.  This decision was made because we wanted to enforce the rule
> that all access to class and instance data should be via self.

I would definitely change that and let all scopes nest, classes too.

A recursive function should be able to refer to itself in the same
way no matter if it's defined at the top level, in another function,
or in a class. The first two cases were unified in 2.1b2, but the
third has not been unified.

 __("<  Marcin Kowalczyk * qrczak at
  ^^                      SYGNATURA ZASTĘPCZA

More information about the Python-list mailing list