Just for fun, I made a copy of one of my Python files with hundreds of occurrences of "self", and I replaced them all with "S". This streamlines things significantly, and I think it looks good, but I suppose most Python aficionados would be aghast. I'm thinking about doing it permanently for all my files. I normally avoid single-character names, but I think this case could be a reasonable exception. What would you think if you saw this in "production" code? --Russ On Mon, Aug 25, 2008 at 3:35 AM, Brandon Mintern <bmintern@gmail.com> wrote:
On Mon, Aug 25, 2008 at 3:45 AM, Bruce Leban <bruce@leapyear.org> wrote:
Jim Jewett wrote: On Sun, Aug 24, 2008 at 6:26 PM, Terry Reedy <tjreedy@udel.edu> wrote:
If m is an attribute of type(s) (which is s.__class__), this shrinkage
is
a convenient abbreviation, not a requirement. The above calls are the same as type(s).m(s.a,b,z) or type(s).m(s,a,b). Or, if you prefer, fn = type(s).m # or s.__class__.m fn(s,a,b,z) If m is an attribute s, and s in not a class, the shrinkage is not available, and one must write s.m(s,a,b,z) or s.m(s.a,b).
Terry Jan Reedy
If I could write:
class foo: def self.bar(): self.rebar(self.babar)
then the call to object.bar() would match the declaration.
+1. I like this proposal: it's clean and sensible, and I think it looks a lot more clear, especially to someone who is new to Python.
Back to Russ's proposal: it would be better accomodated IMHO by allowing $ as a character in a variable name, just like _ is. Then, conventionally, people could use $ as self:
def $.bar(): $.rebar($.babar)
and for whatever it's worth, I find $.bar easier to read then $bar as the explicit dot reminds me it's doing an attribute get rather than looking like a special variable name.
+1 I'm in agreement here as well. The closest I would get to supporting the $-for-self. proposal is allowing $ in variable names. Having used Lisp before Python, I'm used to just about any character being allowed in identifier names. The more characters available, the more expressive the names can be, and I think it could only help things. The overhead of people having to get used to new symbols being used in variable names would be small in comparison to the flexibility offered.
Brandon _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas