[Python-3000] Removing 'self' from method definitions

[Nick Coghlan]

Michael Chermside wrote:
> Ian Bicking writes:
>> I propose that the self argument be removed from method definitions.
> 
> This is not a new proposal. The fundamental problem is a perceived
> mismatch between the argument list used for calling and the argument
> list used in defining the method. Of the many times that it has been
> proposed, the best syntax I have seen was as follows:
> 
>     def self.my_method(arg1, arg2):
>         # body goes here
> 
> In other words, make the definition look like the invocation. In
> this proposal "self" is not magical, it is simply declared in a
> slightly different location. The syntax would be used by sensible
> people only when defining methods, but there would be no such
> rule enforced by the interpreter, nor would the existing syntax
> be broken or prohibited.
> 
> To be abundantly specific, the proposal is that if the next two tokens
> after a "def" were "self" and "." then the result of compiling such
> code would be exactly the same as if they were not present but "self"
> and "," were inserted immediately after the opening parenthesis.
> Whether to allow any identifier or only the particular identifier
> "self" is an interesting question that I would leave for Guido.
> 
> Personally, I favor doing this. I think that making declarations look
> similar to invocations is very useful.

As you say, we could do this just as a grammar tweak, with:

   def NAME1.NAME2(ARG_SPEC):
       BODY

being syntactic sugar for:

   def NAME2(NAME1, ARG_SPEC):
       BODY

Doing this would, however, rule out the possibility of allowing that syntax to 
be used for monkey-patching by interpreting it as:

   def _f(ARG_SPEC):
       BODY
   NAME1.NAME2 = _f
   del _f

I'd also be concerned that this second possible interpretation could easily 
lead to confusion if the syntax were ever used outside a class definition. So 
what if this syntax was permitted *only* within the body of a class 
definition? Aside from monkey-patching (which this doesn't do) is there a use 
case for supporting it anywhere else?

Anyway, below is an example of method definitions of a real class 
(Queue.Queue) updated to use this method syntax. I like it, I really, really 
like it - the methods are defined exactly the way they're typically meant to 
be called. Currently, I have to think when reading a class's source in order 
to figure out what the method signatures actually are - with this syntax, it 
just leaps out at you.

Cheers,
Nick.

-------------
class Queue:
     def self.__init__(maxsize=0):
         # ...

     def self.task_done():
         # ...

     def self.join():
         # ...

     def self.qsize():
         # ...

     def self.empty():
         # ...

     def self.full():
         # ...

     def self.put(item, block=True, timeout=None):
         # ...

     def self.put_nowait(item):
         # ...

     def self.get(block=True, timeout=None):
         # ...

     def self.get_nowait():
         # ...

     # Override these methods to implement other queue organizations
     # (e.g. stack or priority queue).
     # These will only be called with appropriate locks held

     # Initialize the queue representation
     def self._init(maxsize):
         # ...

     def self._qsize(self):
         # ...

     # Check whether the queue is empty
     def self._empty():
         # ...

     # Check whether the queue is full
     def self._full():
         # ...

     # Put a new item in the queue
     def self._put(item):
         # ...

     # Get an item from the queue
     def self._get():
         # ...




-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org