Object Oriented vs Pythonic Code, and Pythonic standards

Discussion in 'Python' started by Carl J. Van Arsdall, Feb 7, 2006.

  1. 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

    Build and Release
    MontaVista Software
    Carl J. Van Arsdall, Feb 7, 2006
    #1
    1. Advertising

  2. Carl J. Van Arsdall

    Paul McGuire Guest

    "Carl J. Van Arsdall" <> wrote in message
    news:...
    > 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
    Paul McGuire, Feb 7, 2006
    #2
    1. Advertising

  3. Carl J. Van Arsdall

    Roy Smith Guest

    Carl J. Van Arsdall <> 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.
    Roy Smith, Feb 7, 2006
    #3
  4. Carl J. Van Arsdall

    Guest

    QOTW candidate...

    >>>>> "Roy" == Roy Smith <> 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
    , Feb 7, 2006
    #4
  5. 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"...
    Bruno Desthuilliers, Feb 7, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Hathaway
    Replies:
    0
    Views:
    400
    Robert Hathaway
    Jul 29, 2003
  2. Robert Hathaway
    Replies:
    0
    Views:
    406
    Robert Hathaway
    Jul 29, 2003
  3. Ville Vainio
    Replies:
    15
    Views:
    471
    Ville Vainio
    Jul 4, 2004
  4. Replies:
    2
    Views:
    404
    Bruno Desthuilliers
    May 26, 2008
  5. rolo
    Replies:
    3
    Views:
    164
    Robert Klemme
    Apr 9, 2004
Loading...

Share This Page