#- When doing object-oriented stuff, it bothers me to have to
#- type "self" so
#- many times.  I propose that Python allow the programmer to
#- optionally type
#- ".variable" instead of "self.variable" to mean the same
#- thing.  Of course,
#- the interpreter would have to be more careful about
#- detecting floats that
#- begin with just a period as in ".5".  What are your thoughts?

I type less than read, so I prefer the code to be better readable than
writable.

I'm -1 on your proposal.

class x:
   def __init__(s,val):
      s.val = val

   def display(s):
      print s.val

That's only one more character than your "." and it doesn't require any changes to Python.
Of course, you'd be breaking with the tradition of naming the instance as "self" but so would your magic "." method.

If you find yourself typing "self" a lot you can also do :

s = self
s.doSomething()

Sometimes python asks us to do things that are against our sensibilities (whitespace comes to mind) but once we try it for a while we find our knee-jerk reaction to change it was simply misplaced.

Live with the language a bit, use it a bit, give python the chance to change you before you try to change python.

Use python for a week or two more and see what I mean.

        with self
                .firstname = 'Brian'
                .surname = 'Trubshaw'
                .occupation = 'Test Pilot'
                .ovine_experience = 'Unknown'

I guess

http://www.python.org/doc/faq/general.html#why-must-self-be-used-expl...

http://www.python.org/doc/faq/general.html#why-must-self-be-used-expl...

Seemed crazy to me at that time, but now after giving a try
to python I've to say that self-consciousness isn't bad.

This following is not a carefully thought one but I would be
interested to know what your opinions are. The following is inspired
by win32all.

<from Python COM  docs>
class HelloWorld:
    _public_methods_ = ['Hello']
    _public_attrs_ = ['softspace', 'noCalls']
    _readonly_attrs_ = ['noCalls']

    def __init__(self):
        pass
</from Python COM  docs>

How about having an optional attribute for a class that negates the
requirement for self?

One advantage with this is I can see all the member variables in one
place. Great while reading code.

<sample>
class FooBar:
    __public__ = [Name, Age]
    def setName(name):
        Name = name
</sample>

While I am complaining, a few other peeves ...

Another thing is I dislike is having to use __ for *every* private
variable. For *me* __private__ at the top of the class definition code
would be more elegant. __readonly__ would be another nicety.

Introducing the above attributes into the language would not likely
break any existing Python code.

        There was the "with" keyword :

        with self:
                .member = something
                .member2 = .member3 + .member4

class Person:

     def setName(_, name):
         _.name = name

     def getName(_):
         return _.name

But other Python programmers will hate you for it ;-)

If it is because you are using an attribute too many times inside a
method, a better solution is to map it to a local variable. It also has
the advantage of being faster.

class SoftwareProjectEstimator:

     pi = 3.14

     def guestimatePrice(self, hours, hour_price, developer_group_size):
         pi = self.pi
         guess = hours * pi
         guess *= pi * developer_group_size
         return guess * hour_price

At the time my main job was helping hundreds of other programmers debug
their hairiest bugs (also helping them architect and design and test
things correctly, but debugging took far more time -- there's never time
to do it right so there's always time to do it over) and the lack of
this-> was a major cause of problems. confusions and bugs.

As long as you're just yakking about it ain't gonna happen -- become a
metaclass and bytecode expert and you can implement this in Python, or
convince somebody who is such an expert, for which the implementation
should be the job of a couple days tops.

One impossible task (THAT would require hacking the Python parser and
changing things very deeply) as I already mentioned would be the form
you want for the assignment to __public__ (or similarly to
__private__etc).  Those names are undefined (or worse defined globally)
and to teach Python (and human readers!) that for that one speclal case
of assignment to __public__ (or __private__), THAT one case only,
COMPLETELY different rules apply than ANYWHERE else in Python, well,
it's just as difficult as it is absurd.

I suggest you tackle the 'look ma no quotes!' task last, after
everything else is working, because that one detail is going to take far
longer than everything else put together, even if you're learning about
metaclasses and bytecodes from scratch.

The fact that there are plenty of C++ and Java coding conventions
which require that all class members' names start with "m_", or that
all instance attributes be accessed, in methods, via "this->" or
"this."  (depending) on the language in question, seems to support
Python's choice in this matter.

Going back to look at C++ code (whoever wrote it) makes me realise
how helpful it is to have an explicit marker as to what's belongs
to a class and what doesn't. And before anyone mentions Hungarian
notation, (a) is 'self.' *really* that much more of an imposition
over 'm_'? and (b) it's not useful for distinguishing methods from
functions.

I wish I could rise up to your challenge and do all that stuff.
Regretfully, my Python skills don't extend to metaclasses and
especially "byte code hacking". Maybe you will explain those in your
next edition of the cookbook :-).

"Ravi Teja Bhupatiraju" <webravit...@yahoo.com> wrote in message

or if you want to use meta-classes (and this recipe does use __readonly__):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/197965

There are many similar implementations floating around.

As for removing self:
http://starship.python.net/crew/mwh/hacks/selfless.py

So I did cover metaclasses in "Python in a Nutshell" as well as in
dedicated presentations (you can find the presentations' PDFs on the
usual site, www.strakt.com) and I will probably select a few metaclass
recipes for the second edition of the Cookbook.