Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
Sender: chris@rebertia.com
In-Reply-To: <CAKz-UDNFpHF=2secHaFJ2M7LKAD4XtLLrqmE3uo1A6YVXH1zTg@mail.gmail.com>
References: <CAKz-UDNFpHF=2secHaFJ2M7LKAD4XtLLrqmE3uo1A6YVXH1zTg@mail.gmail.com>
Date: Thu, 22 Mar 2012 04:17:35 -0700
Subject: Re: Python classes: Simplify?
From: Chris Rebert <clp2@rebertia.com>
To: Steven Lehar <slehar@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.881.1332415064.3037.python-list@python.org>
Lines: 74
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:22012

On Thu, Mar 22, 2012 at 3:51 AM, Steven Lehar <slehar@gmail.com> wrote:
> It seems to me that the Python class system is needlessly confusing. Am I
> missing something?

Explicit `self` is slightly annoying, but you'll get over it quickly (trust=
 me).

> For example in the class Complex given in the documentation
>
> class Complex:
> =C2=A0 =C2=A0 def __init__(self, realpart, imagpart):
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.r =3D realpart
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.i =3D imagpart
>
> x =3D Complex(3.0, -4.5)
>
> I initially found it profoundly confusing that __init__( ) calls for 3
> arguments, but you call Complex( ) with 2.

That's not at all unique to __init__().

> Furthermore, why not call the
> initialization function after the class name as is done in other language=
s?

Yech. That would add another step to renaming a class and make
referring to the superclass initializer method rather difficult. It
would also break the "all special methods have underscored names"
rule.

Perhaps you'll find the following instructive:
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
>>> class Foo(object):
...     def __init__(self):
...         pass
...
>>> Foo()
<__main__.Foo object at 0x100fd5750>
>>> Bar =3D Foo
>>> Bar.__name__ =3D "Bar"
>>> del Foo
>>> # look Ma, I've renamed the class!
>>> Bar()
<__main__.Bar object at 0x100fd57d0>

How would your scheme account for this possibility?

> Isn't that the simplest conceptually? Demonstrating with the above exampl=
e:
>
> class Complex:
> =C2=A0 =C2=A0 def Complex(realpart, imagpart):
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Complex.r =3D realpart
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Complex.i =3D imagpart

Your change of "self" to "Complex" in the method body here makes no sense t=
o me.

> x =3D Complex(3.0, -4.5)
>
> Is there a good reason why classes cannot be defined that way? (Besides t=
he
> problem of backward-compatibility)

Mostly historical, IMO. But here are some justifications for explicit `self=
`:
http://docs.python.org/faq/design.html#why-must-self-be-used-explicitly-in-=
method-definitions-and-calls
http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

Cheers,
Chris R.
--
http://blog.rebertia.com