Two minor syntactic proposals
Gareth McCaughan
Gareth.McCaughan at pobox.com
Sun Jun 17 19:18:07 EDT 2001
phil hunt wrote:
[I expressed distaste for the following and proposed another syntax:]
> > def new_method(self, x):
> > something_else()
> > return x+1
> > Thing.new_method = new_method
>
> It doesn't look too bad to me. It's not as if you'd be doing it
> every day, I expect. And i don't think special syntax for
> operations your rarely use is a good idea -- because people
> will use them too infrequently to remember the syntax.
I think it would be used more if it didn't feel like grovelling
around in the insides of things you're not supposed to touch.
Of course, maybe that's an argument for leaving things as they
are. :-)
> >Every now and then we get people complaining because it's
> >too easy for them to forget to include a "self" argument
> >in a method definition. Every now and then, I suspect that
> >most Pythonistas forget. (I certainly do.) Suppose there
> >were an alternative syntax, thus:
> >
> > class Thing:
> > def self.boring_method():
> > return 0
>
> I propose a different way of doing this: make 'self' implied in all
> references to instance variables. This involves definiing 2 new keywords,
> qclass and insvars. So:
>
> qclass Thing:
> insvar v, w
> def myMethod(p):
> print p, v, x
> def otherMethod():
> myMethod(1)
> someFunction()
>
> would be equivalent to:
>
> class Thing:
> def myMethod(self, p):
> print p, self.v, x
> def otherMethod(self):
> self.myMethod(1)
> someFunction()
I confess that my initial reaction is "eeurgh", which may well
be how others react to my proposals. I think your qclass/insvar
proposal breaks the following principles of Pythonic style:
- "Explicit is better than implicit" (one of the timbots
rules from way back). "self" really *is* a function argument,
and eliminating all mention of it feels uncomfortable.
Not to mention that "qclass" binds "self" without saying
so. Is there anything else in Python that binds things
that it doesn't mention? I can't think of any right now.
- "No cryptic identifier names". Why "qclass"? Why not
"xclass" or "zclass"? (Does the "q" actually stand for
something?) How easy will it be to remember that it's
"insvar", not "instvar" or "insvars"?
> Note that a qclass definition would have to know what its methods and instance
> variables were, including those inherited from superclasses, for this to work.
> Is this feasible?
I don't understand what you mean by "know what its instance variables
are"; new instance variables can materialize on the fly on a per-class
or per-instance basis. Anyway, why would it need to know that?
--
Gareth McCaughan Gareth.McCaughan at pobox.com
.sig under construc
More information about the Python-list
mailing list