Object Oriented vs Pythonic Code, and Pythonic standards

[Paul McGuire]

"Carl J. Van Arsdall" <cvanarsdall at mvista.com> wrote in message
news:mailman.1561.1139337813.27775.python-list at python.org...
> It seems the more I come to learn about Python as a langauge and the way
> its used I've come across several discussions where people discuss how
> to do things using an OO model and then how to design software in a more
> "Pythonic" way.
>
> My question is, should we as python developers be trying to write code
> that follows more of a python standard or should we try to spend our
> efforts to stick to a more traditional OO model?
>
> For example, in C++ I might make a file that defines a class and all its
> methods, at which point I create an object and do things with it.  My
> interpretation of what is "Pythonic" would be instead of creating a
> class I would just define functions and maybe some variables global to a
> module.  At this point, I import the module and just make function calls.
>
> There are many similarities here, but the difference is that in python I
> don't feel as though I would define a class, I would just treat the
> python module as a class instead, especially if it was a type of object
> that I would only need a single instance of.
>
This is only the case if you are using classes in C++ just to organize
functions into an object, treating the class primarily as a namespace.  If
all of your methods are static to the class, or if your program only
instantiates a single object and then uses it as the accessor to the
contained methods, then you might as well just declare these globally in a
module, as you have described.  (If you are porting from Java, this is
especially possible, even likely, since the class-zealotry of Java's design
foists the class structure on all code, whether it is suitable or not.)

However, if your application organizes itself into granular objects, along
the lines of many established OO design techniques/patterns, then by all
means, use Python's class definition capabilities, and implement your class
much as you describe doing so in C++.

Note, however, that much of the "traditional OO model" conventional wisdom
is born of C++ and Java's type-static nature.  The penchant for
interface-based design, for example, is enabled and abetted by those
languages' compile-time verification of the implementation of abstract
methods in deriving classes - Python has no such feature.  Instead, Python
objects are verified for method implementation at run-time, by the direct
technique of calling the method, and raising an exception if it is not
found.  This is not to say that interfaces have no place in Python design or
programming, they simply are not enforced by the compiler/interpreter.
Other techniques found in resources such as "Effective C++", an excellent
book by Scott Meyers, have much more to do with coping with C++ memory
management and type-rigidity, and less to do with OO concepts.  Things like
<auto_ptr>, or Meyers' envelope-letter idiom, are just non-issues in Python,
although they take up volumes of explanation for C++ users.

Conversely, the amorphism of Python objects, such as the ability to
dynamically (even casually) "hang" new attributes on an existing object,
without prior definition, is nearly unknown in the C++ and Java worlds, and
not without significant contortions.  This one feature alone enables
entirely different approaches to object modeling, and permits the creation
of new design patterns that are especially suited for Python.  (I almost
termed this aspect as "Python-unique", but I think this would probably show
my ignorance of similar features in languages such as Haskell or Lua.)

The traditional OO concepts that are associated with dynamic/run-time
type-checked languages such as SmallTalk are probably more directly
translatable to Python.  But even in SmallTalk, *all* code must be
implemented within the context of a class.  And the implementations of those
concepts can also be much lighter-weight in Python, than they need be in
C++.

This topic is also covered in some detail in the two blog entries: "Python
is not Java" (http://dirtsimple.org/2004/12/python-is-not-java.html), and,
"Java is not Python, either"
(http://dirtsimple.org/2004/12/java-is-not-python-either.html).

> The second question that arises from Pythonism is, has the community
> drafted a standard for quality "Pythonic" code?
>
There is a PEP for this, I think it's PEP8.  But I believe these are more
"guideline"-level recommendations, not "standards".

-- Paul