confused if i should be doing type checking in the code ( a confused java programmer)

Alex Martelli aleax at aleax.it
Sun Jan 6 06:27:33 EST 2002


Karthik Gurumurthy wrote:

> had trouble implementing immutable constants in python

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65207

> I was trying to emulate the java enum equivalent but was not able
> implement it successfully.

That's a different issue, see
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/67107

> Since this kind of a things cannot be done in python ,should i be writing
> this kind of code in python as well??

Absolutely not; it would be a serious mistake.

> if i do that then all my python functions and methods will be littered
> with such type checking code!

And by defeating Python's intrinsic signature-based polymorphism, you'll 
make your modules substantially less useful.

> even after a couple of months of python..i think i have not been able to
> understand the differences in the way
> you code in java and python!  :-(

I think the Python Cookbook provides interesting style examples.  For now, 
there's only the online version at the above-mentioned URLs, but we're 
working on an edited and organized "paper version" which O'Reilly will soon 
publish.

> probably am missing something here..the purpose of the 2 languages appear
> to be very different to me now.

The purpose may be the same, but the approach to get there is drastically 
difference.  Python's way is simplicity, dynamism, flexibility, uniformity. 
 Java chooses type-checking and rigidity (not as consistently as other 
languages, e.g. Eiffel).


> anyways,
> i took a look at the __slots__ concept as well which i guess does not
> allow us to add attributes to an instance.

Adding __slots__ to a 2.2 class lets that class's instances be smaller, by 
not carrying a dictionary each.

> I saw a recipe for writing properties. That was smart!
> But now python supports properties at syntax level. I tried that out with
> py2.2

Yes.

> Then what prevents python from having a final equivalent when we could
> have such nice things like properties?

Nothing prevents you from writing a metaclass that forbids subclasses from 
doing certain overrides.  I think it would be an utter waste of substantial 
time and energy, but it has never been Python's way to stop you from doing 
silly things: Python gives you simple and effective tools, and makes it 
simplest to code in the most effective ways, but the tools are powerful 
enough that you can also use them badly.

I recently posted a metaclass to perform the reverse (and IMHO similarly 
ill-conceived) task, _forcing_ subclasses to override certain methods in 
order to become instantiable.  The prohibition is even easier to enforce.  
In a few lines of code, you can substantially reduce your own productivity 
and that of everybody else who chooses, or is forced to, use your metaclass.

I don't think it makes sense to do it, but, if you disagree, go right ahead!


Alex




More information about the Python-list mailing list