Wednesday, December 21, 2011

Defending Class Finality in Python

Back when Record was defined in DataConnectors (part 4), I had an inkling that a nominally final class would be viewed as "not Pythonic." I still struggle with what, exactly "pythonic" really means, though there are several results that look promising for various searches on Google, including pythonic code. The reason that the precise definition of Pythonic is a sticking point for me (at least right now) is that when I was looking to see if there was a standard mechanism for making final (non-extendable) classes, I ran across several mail-list items, blog-posts, and other resources on the web that all seemed to present more or less the same reason for discouraging class finality in any way:

Who are you to say that a class cannot be extended?
Having given it some thought, I have a two-part response (not necessarily an answer) to that question:
I am the person who created the class in the first place, who thus arguably knows (and at least should know) what all of the design- and implementation-decisions were for it, and who is the most likely to know what is going to break if a haphazard extension of that class is made.
Given the very nature of Python, and (at least for my part) the intention of releasing the code rather than just the executable in good open-source tradition, by making a class nominally final as I have in a few cases so far, I am not saying that the class cannot be extended. Anyone who feels the need to extendit has access to the code, and can remove the nominally-final constraint I have put in place. What I am saying is that the class wasn't intended to be extended, and if you want to extend it, you'd better at least look at my code first.

As to what "Pythonic" means...? Well, this seems to be a popular (and detailed) explanation. I'm not very far into it just yet, but at the very least, it looks to be an enjoyable read...

No comments:

Post a Comment