Whatever you all propose,

coming from a java and c++ background, OOP in python is quite cumbersome.

if you tell that i am not a python guy, then consider that current oop
style does not reflect python's style of ease and simplicity

is __init__ really a good syntax choice?

Abdur-Rahmaan Janhangeer,
Mauritius
https://abdurrahmaanjanhangeer.wordpress.com

On 14 May 2017 11:05, "Steven D'Aprano" <st...@pearwood.info> 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?
>
> 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?
>
> Why is self an instance of the parent class, instead of MyClass?
>
>
> >       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?
>
>
> >       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-ideas@python.org
> 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/

Reply via email to