creating class objects inside methods

Carl Banks pavlovevidence at gmail.com
Sun Oct 4 09:09:55 CEST 2009


On Oct 3, 11:14 pm, horos11 <horo... at gmail.com> wrote:
> Carl,
>
> Thanks for the info, but a couple of points:
>
>     1. it wasn't meant to be production code, simply a way to teach
> python.

I understand, and if you think it's overkill for your pedagogical
application then feel free not to follow the suggestions I gave you.


>     2. this should either be a compile time or a runtime error.
>
> 'Actions at a distance' like this are deadly both to productivity and
> to correctness - not only is this a runtime error, it is a *silent*
> runtime error. Any other language I know would catch this, whether it
> be lua, java, or perl.

I'm afraid that's just not reasonable given the nature of classes in
Python.  Python made a deliberate design trade-off by treating classes
as first-class objects.  This decision carries benefits and
drawbacks.  You've seen one of the drawbacks.  Benefits include
simpler data model and increased opportunities for dynamicism.  Perl,
Java, and Lua made the opposite choice, thus they are able to catch
the above mistake.

You could argue that Python made the wrong choice, and that classes
ought not to be first-class objects.  Fine.  But it didn't, and the
protection you seek is sacrificed.

I suggest looking at tools like PyChecker and PyLint.  I don't know if
they'd have found your error in this case, but they can find a lot of
problems Python itself misses.


> Saying that 'whoa, this coding error should be handled by naming
> convention' may be the only practical way of getting around this
> limitation, but it is a limitation nonetheless, and a pretty big one.

I believe it's a miniscule limitation in practice.  It seems like a
big deal but doesn't actually happen much.  YMMV.


Carl Banks



More information about the Python-list mailing list