Object Oriented vs Pythonic Code, and Pythonic standards

[Carl J. Van Arsdall]

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.

The second question that arises from Pythonism is, has the community
drafted a standard for quality "Pythonic" code?

Thanks,

carl

--

Carl J. Van Arsdall
cv*********@mvista.com
Build and Release
MontaVista Software

[Paul McGuire]

"Carl J. Van Arsdall" <cv*********@mvista.com> wrote in message
news:ma***************************************@pyt hon.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-i...n-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

[Roy Smith]

Carl J. Van Arsdall <cv*********@mvista.com> wrote:

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?
There is much about traditional OO which translates well to Python,
but sometimes it is difficult to read a treatise on OO and tell which
bits are "traditional OO" and which are "OO in C++/Java".

Traditional OO teaches that tight coupling of classes is bad, and this
is just as true in Python as it is in any language.

Many OO adherents also push lots of unit testing and test-driven
development; this works just as well (perhaps even better) in Python
as it does in other langauges.
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.
In general, defining classes and methods works in Python just like it
does in C++. Your idea of making a module just a collection of functions
would correspond to defining a bunch of functions inside a namespace
in C++. There are times when it might make sense, such as the math
module, but it would be unusual.
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.

Why not? Read up on the "singleton pattern".

Where OO in Python differs significantly from OO in C++ is anything
having to do with strict type checking. There are lots of design
patterns that have to do with insulating classes from the types of
things they interact with. In Python, that's mostly a non-issue
because of Python's dynamic typing. If you ever see yourself
obsessing over the types of arguments, that's the time to ask yourself
if you're trying to do something unpythonic.

Another place where OO in Python tends to be at odds with OO in
C++/Java is data hiding. Traditional OO dogma is that ALL data should
be private, accessed externally only through dedicated get()/set()
methods. Python code tends to reject that (for reasons that I only
partially agree with). In C++, you would say foo.setValue(x), but in
Python you would just say foo.Value = x. There's nothing that says
you can't make all data private (with the underscore syntax) and write
setter/getter methods, but that's not the style that's commonly used.
Part of the reason is because in Python you can intercept all
attribute access with __getattribute__(), and __setattribute__(), but
I suspect another part of it is an emotional reaction to C++'s B&D
style of coding. I'm not trying to persuade you one way or the other
here, but you should be aware of both styles.

[Bruno Desthuilliers]

Carl J. Van Arsdall a écrit :

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.
Well, Python being mostly OO (about 101% I'd say), doing things "the
Pythonic way" and doing things "the OO way" often overlap.
My question is, should we as python developers be trying to write code
that follows more of a python standard
Yes - given that this "standard" is a moving target (as Python grows and
changes, so does pythonic idioms).
or should we try to spend our
efforts to stick to a more traditional OO model?
Depends on what you call a "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.
I think you should have a closer look at the standard lib. I did not run
an exhaustive analysis, but it seems to me that it's mostly built around
classes.
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.
Strange enough, that's *exactly* what is it. Python modules *are*
instances of class module - like functions are instances of class
function, and even classes are themselves instance of their metaclasses...

I'm afraid that years of C++/Java/Ada/C# and other class-based,
statically typed languages domination results in (too) many programmers
confusing *object* oriented with *class* oriented.

As an example, most of the functional programming support in Python
comes from the fact that functions are objects too (which is the first
and mandatory requirement for fp) and that any class can also become a
new 'type' of function. So, are Python's function decorators
'functional' or 'oo' ? HigherOrderFunctions are of course typical of fp,
but the way they work in Python is mostly OO (yes, this is the good old
Decorator pattern, applied to function objects...)
The second question that arises from Pythonism is, has the community
drafted a standard for quality "Pythonic" code?

launch your Python interactive interpreter and type "import this"...

[skip]

>>>>> "Roy" == Roy Smith <ro*@panix.com> writes:

Roy> There is much about traditional OO which translates well to Python,
Roy> but sometimes it is difficult to read a treatise on OO and tell
Roy> which bits are "traditional OO" and which are "OO in C++/Java".

+1 QOTW...

Skip