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