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 :-)
>
> Thanks!
> > Wouldn't it be nice to define classes via a simple constructor function
> (as
> > below) instead of a conventional class definition?
>
> No.
>
> > *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
> explicit.
>
>
> > *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
> method?
>
> 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.
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> python...@python.org <javascript:>
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
