Inheriting the @ sign from Ruby

Alex Martelli aleaxit at
Tue Dec 12 05:38:07 EST 2000

"Roy Katz" <katz at> wrote in message
news:Pine.GSO.4.21.0012120138090.2874-100000 at
> I was reading a Dr. Dobb's recently and it mentioned that Ruby uses the @
> symbol to denote instance members of a class.  This appeals to me because
> I can comprehend it faster than seeing 'self' pasted in front of a
> name, especially when the statement is buried in dense code.

'self' is not "pasted in front of a name" -- 'self' is an object,
and it is used with perfectly regular syntax for object access.

Thus, there is no special-case syntax needed: the regular syntax,
which you need anyway for general cases, takes care of everything
in the special-case as well.

> Why not bind @ to the first argument of method definitions? Consider:
>   class X:
>     def __init__( self, x ):
>       @bind(x)     # binds to 'self', because
>                    # 'self' is the first argument to __init__

If you called
you WOULD know what that does, right?  Call method 'bind' on
that object with 'x' as an argument.

does exactly the same thing, simply and predictably -- the
object on which 'bind' is called being, unsurprisingly,
the one named 'self'.

So, you would like '@identifier' to be a special-case
syntax meaning exactly the same as 'self.identifier' (if
the first argument, as per normal convention, is named

>     def bind(myself, x):
>       @x = x   # equivalent to myself.x

The violation of the convention (using 'myself' instead
of 'self' as the name of the first argument) is not
remedied by the '@' kludge, of course.  Whenever a use
of 'self' is desired, that cannot be brought to the
attribute-access syntax of self.whatever (passing
'self' as an argument to getattr, or to a base-class
version of a method, etc, etc), such a violation of
normal expectations will make your code harder to read
and understand by any maintainers.

I'd much rather have a lint-like checking that the
argument expected to be named self is in fact thus
named, with a warning when it isn't.

> What faults or strengths do you see with this?

I see no strength in this supplementary syntax form
offering a second, different way to express what can
be perfectly well expressed explicitly today.

I see it as a fault that all this does is offer a
second, different way to express what can be perfectly
well expressed explicitly today.

It would also be a (small) step along the road of
turning the currently crystal-clear syntax of Python
into that morass of special-purpose, ad-hoc, 'convenient'
kludges that make certain other languages' typical
programs look so peculiarly similar to line noise.


More information about the Python-list mailing list