On Sunday, May 14, 2017 at 3:05:46 AM UTC-4, Steven D'Aprano wrote:
On Sun, May 14, 2017 at 04:07:44AM +0000, Simon Ramstedt wrote:
> Hi, do you have an opinion on the following?

Hi, and welcome, and of course we have an opinion! This is Python-Ideas,
we're very opinionated :-)

> Wouldn't it be nice to define classes via a simple constructor function (as
> below) instead of a conventional class definition?


> *conventional*:
>     class MyClass(ParentClass):
>       def __init__(x):
>         self._x = x
>       def my_method(y):
>         z = self._x + y
>         return z

Looks good to me. It is nicely explicit that you're creating a class,
the superclass or superclasses are easy to see, and the attributes are

> *proposed*:
>     def MyClass(x):

That is the exact same syntax for defining a function called "MyClass",
that takes one argument, x. How is Python (and the reader!) supposed to
tell which calls to def return a class and which return a function?

>       self = ParentClass()

What if you have multiple parent classes?

    Right, the parent class would have to specifically written to allow that e.g. via:
 def ParentClass(obj=None):
    self = obj or Object()
Why is self an instance of the parent class, instead of MyClass?

That's what I've tried to cover under "(+/-) Checking types: ..."

>       def my_method(y):
>         z = x + y
>         return z

The local variable x is not defined. Wait, is that supposed to come from
the closure def MyClass(x)?

What if your class has twenty methods, each of which takes different
arguments? Do you have to write:

def MyClass(x, # used in my_method
            y, # used in another_method
            z, # used in third_method,
            a, b, c, # used in fourth_method
            ...  # blah blah blah

How does this generalise to non-toy classes, classes with more than one

def MyClass would basically as a replacement for __init__. Using __init__ instead for your example would also not be perfect:

def __init__(self, x, y, z, a, b, c):
   self._x = x
   self._y = y

The point is though, that you could still do exactly the same if you wanted to:

def MyClass(x, y, z, a, b, c):
   self = SuperClass()
   self.x = x
   self._y = y
   def my_method():
     self.x += 5
     return self.x + self._y

>       self.my_method = my_method  # that's cumbersome (see comments below)
>       return self
> Here are the pros and cons I could come up with for the proposed method:
> (+) Simpler and more explicit.

I think you mean "More complicated and less explicit".

Is this supposed to be some sort of prototype-based OOP instead of
class-based OOP? I'd be interested in investigating prototype-based
objects, but I don't think this is the way to do it.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/