Life of Python

Discussion in 'Python' started by Uwe Mayer, Jun 25, 2005.

  1. Uwe Mayer

    Uwe Mayer Guest

    Hi,

    I have come across the following statement a number of times:

    http://mail.python.org/pipermail/python-list/2003-July/171805.html
    [... how to enforce pure abstract class ...]
    > Python, in general, doesn't try to stop the programmer doing things, the
    > way many other languages do. This is known in the community as the
    > "we're all consenting adults" philosophy.


    I have a split opinion on that:

    pro: If you're writing smaller apps and everything stays rather clearly laid
    out you don't need to care about abstract, virtual, accessor functions,
    private, public, interfaces, etc

    con: If you are planning larger applications (for a reasonable value of
    "large") you have to discipline yourself to write well structured code.
    Then you will want to specify interfaces, accessor functions with different
    read /write access, ...
    Unless you have designed the software interactions completely bevorehand
    (which never works out) this is the only way to incorporate changes without
    refactoring your source all the time.

    Therefore I come to the conclusion that a general purpose language like
    Python may well allow tampering with name-mangeling, dynamic method
    resolution, whatever, BUT it should also provide facilities to allow
    enforcing a more structured approach.

    This is why I welcome i.e. the decorator support in Python 2.4. And I think
    this should be expanded further, i.e. more build-in decorators for
    interfaces, abstract classes, parameter and return value restrictions.
    You can, but you must not; and I use both, depending on the project I'm
    working on.

    IMO this is a problem i.e. Perl is faceing: you can do even more rubbish
    with Perl than with Python and since there is no way of forcing a
    programmer to do it a certain way, its often easyer to rewrite Perl
    programs over 400 lines than to fix them.

    Ciao
    Uwe
    Uwe Mayer, Jun 25, 2005
    #1
    1. Advertising

  2. Uwe Mayer

    Benji York Guest

    Uwe Mayer wrote:
    > con: If you are planning larger applications (for a reasonable value of
    > "large") you have to discipline yourself to write well structured code.


    This is definitely true, no matter the language you use.

    > Then you will want to specify interfaces,


    If you're really interested in interfaces you might want to check out
    Zope3. Even if you don't want to use the "web" parts, the component
    architecture parts (interfaces, adapters, etc.) might be interesting to you.

    In a related vein is PEAK (http://peak.telecommunity.com/). It also has
    some related ideas about interfaces, components, adapters, etc.

    > accessor functions with different read /write access, ...


    I don't quite follow here. Are you talking about using a method like
    "thing.getX" instead of just accessing the attribute directly like
    "thing.x"? If so, that kind of up-front design isn't necessary in Python.

    > Unless you have designed the software interactions completely bevorehand
    > (which never works out) this is the only way to incorporate changes without
    > refactoring your source all the time.


    Refactoring *is* the way you handle not being able to "[design] the
    software interactions completely bevorehand".
    --
    Benji York
    Benji York, Jun 25, 2005
    #2
    1. Advertising

  3. On the accessor function topic. Here is a good description of why you
    don't need accessors in python (among other things) written by the
    main PEAK(http://peak.telecommunity.com/) developer (Phillip J. Eby):
    http://dirtsimple.org/2004/12/python-is-not-java.html

    Some other useful articles in a similar vein:
    http://dirtsimple.org/2004/12/java-is-not-python-either.html
    http://naeblis.cx/rtomayko/2004/12/15/the-static-method-thing

    Phillip has written several very interesting python related articles
    on his blog (dirtsimple.org). Also PEAK and the spin off pyprotocols
    have a lot of very interesting tools for helping to manage large
    python projects.

    -Chris

    On 6/25/05, Benji York <> wrote:
    > Uwe Mayer wrote:
    > > con: If you are planning larger applications (for a reasonable value of
    > > "large") you have to discipline yourself to write well structured code.

    >
    > This is definitely true, no matter the language you use.
    >
    > > Then you will want to specify interfaces,

    >
    > If you're really interested in interfaces you might want to check out
    > Zope3. Even if you don't want to use the "web" parts, the component
    > architecture parts (interfaces, adapters, etc.) might be interesting to you.
    >
    > In a related vein is PEAK (http://peak.telecommunity.com/). It also has
    > some related ideas about interfaces, components, adapters, etc.
    >
    > > accessor functions with different read /write access, ...

    >
    > I don't quite follow here. Are you talking about using a method like
    > "thing.getX" instead of just accessing the attribute directly like
    > "thing.x"? If so, that kind of up-front design isn't necessary in Python..
    >
    > > Unless you have designed the software interactions completely bevorehand
    > > (which never works out) this is the only way to incorporate changes without
    > > refactoring your source all the time.

    >
    > Refactoring *is* the way you handle not being able to "[design] the
    > software interactions completely bevorehand".
    > --
    > Benji York
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >



    --
    Christopher Lambacher
    Chris Lambacher, Jun 26, 2005
    #3
  4. Uwe Mayer

    Alan Gauld Guest

    "Uwe Mayer" <> wrote in message
    news:d9jcij$nm6$-karlsruhe.de...
    > con: If you are planning larger applications (for a reasonable

    value of
    > "large") you have to discipline yourself to write well

    structured code.

    As always.

    > Then you will want to specify interfaces, accessor functions

    with different
    > read /write access, ...


    Why? What advantage does this really give you over indicative
    doc strings? interfaces in particular are a modern madness.
    Why not just define a class with a set of unimplemented methods.
    Who cares if someone tries to instantiate it? What can they do
    with it? They only make sense in languages which are statically
    typed and rely on inheritance to implement polymorphism.

    Pure accessor methods are usually a mistake anyway, but can
    be done using properties if you really must.

    > Unless you have designed the software interactions completely

    bevorehand
    > (which never works out) this is the only way to incorporate

    changes without
    > refactoring your source all the time.


    On really big projects it is fairly normal to define the
    structure of the code to quite a detailed level - often
    using Case tools and UML etc - so refactoring is only needed
    when you discover a hole. Thats true regardless of size of
    project but the Case approach tends to limit the damage.

    > this should be expanded further, i.e. more build-in decorators

    for
    > interfaces, abstract classes, parameter and return value

    restrictions.

    What kind of parameter and return value restrictions?
    In a dynamically typed language there is a limit to what can
    be applied, and much of that is of limited value IMHO.

    > with Perl than with Python and since there is no way of forcing

    a
    > programmer to do it a certain way,


    I'm always uncomfortable about trying to "force" a programmer
    to do it a certain way. I can never know what circumstances
    those client programmers might be facing when I write/design my
    code. And I can never be sure that I know better than the
    client programmer.

    I've seen too much C++ code that begins

    #define private public

    to believe that trying to force programmers rather than inform
    them is a good idea.

    (And FWIW I have worked on several multi million line projects
    with upwards of 400 programmers working in 5 or more locatons
    in Lisp, C, SQL, COBOL etc. Attempts to impose rules rather
    than agreed protocols have never been very helpful in my
    experience)

    > its often easyer to rewrite Perl programs over 400 lines


    That probably has a lot more to do with Perl's inscrutable
    syntax and "many ways to do it" approach than any of the
    classifiers being discussed here! I certainly didn't find
    us rewriting Lisp code rather than enhancing what was there,
    and Lisp shares much of Python's approach to life.


    --
    Alan G
    Author of the Learn to Program web tutor
    http://www.freenetpages.co.uk/hp/alan.gauld
    Alan Gauld, Jun 27, 2005
    #4
  5. On Monday 27 June 2005 02:34 am, Alan Gauld wrote:
    > "Uwe Mayer" <> wrote in message
    > news:d9jcij$nm6$-karlsruhe.de...
    > > con: If you are planning larger applications (for a reasonable
    > > [...]
    > > Then you will want to specify interfaces, accessor functions

    > with different
    > > read /write access, ...

    >
    > Why? What advantage does this really give you over indicative
    > doc strings? interfaces in particular are a modern madness.


    Interfaces, IMHO are best viewed as documentation. I have used
    the Zope 3 interfaces module, and I think it's going to be very
    useful to me. Although, theoretically, you could do all of this
    with doc strings, being able to check that you've documented
    everything that should be (including methods and attributes).

    With interfaces, you distribute the docstrings over the class. Also,
    the interpreter helps you with documentation problems, because
    standardized means are used to represent what methods expect
    as arguments, and so on. They don't really force you to do it that
    way, but they generally catch broken attempts to implement the
    interface.

    > Why not just define a class with a set of unimplemented methods.


    Takes too much time, and gets mixed in with functionality.
    Basically, it's more boilerplate than the better interface modules
    written for Python.

    > Who cares if someone tries to instantiate it? What can they do
    > with it? They only make sense in languages which are statically
    > typed and rely on inheritance to implement polymorphism.


    > Pure accessor methods are usually a mistake anyway, but can
    > be done using properties if you really must.


    Yes -- there's just no reason to do that in Python. Properties mean
    you don't have to worry about an attribute changing into a method,
    so there's no reason to try to "preempt the damage". No damage,
    so no preemption needed. I personally, really prefer attributes (or
    properties) over explicit get/set methods.

    > > Unless you have designed the software interactions completely

    > bevorehand
    > > (which never works out) this is the only way to incorporate

    > changes without
    > > refactoring your source all the time.

    >
    > On really big projects it is fairly normal to define the
    > structure of the code to quite a detailed level - often
    > using Case tools and UML etc - so refactoring is only needed
    > when you discover a hole. Thats true regardless of size of
    > project but the Case approach tends to limit the damage.


    Okay. This makes sense if the software is:

    1) Designed by one institution.
    2) Designed almost entirely before deployment.
    3) Not designed to be worked on by users and
    semi-trained developers.

    In other words --- proprietary software.

    For a free-software application, in which you want to maximize
    your collaborative advantage, you want to make one-sided
    cooperation as easy as possible. I do not *know* who my
    collaborators will be. They may well not be privy to UML diagrams
    and CASE tools I may have used. Certainly a lot of them wouldn't
    bother to look if they could avoid it. OTOH, a well-defined
    set of interfaces shows them where they can make clean breaks
    in the design in order to localize what they need to learn and
    what they need to fix -- and it's all right there in the source code.

    It's just like fixing an old house. The biggest problem is knowing
    where to stop --- how much of that plumbing do you want to
    take out and rework? If it has cutoff valves and unions in the
    right places, it will come apart in sections and you have a much
    better chance of fixing it without getting into an intractable mess.
    Software interfaces can be used to the same effect --- making the
    job easier for the next person who comes along.

    If you are trying to trade on a free-software advantage, then it is
    absolutely in your best interest to make the way as easy as
    possible for the people who follow you.

    > > this should be expanded further, i.e. more build-in decorators

    > for
    > > interfaces, abstract classes, parameter and return value

    > restrictions.


    Specifically, *I* would like one of the available interface
    implementations to find its way into the standard library. Obviously,
    *my* life would be easier if it's the Zope 3 implementation, but I'll
    learn to use whatever gets in there.

    > What kind of parameter and return value restrictions?
    > In a dynamically typed language there is a limit to what can
    > be applied, and much of that is of limited value IMHO.


    Yes, there is a limit, and it's madness to go beyond it. But there
    is a useful middle ground. For example, it is quite useful to
    specify that an argument of a method should expect an object
    which implements a given interface. For simple objects, this is
    usually handled by things in the interface module. A method
    which expects a number may check that the object has __add__,
    __mul__, etc.

    But the real win is when it's supposed to be a much more
    elaborate object defined by the application.

    Intelligent use, of course, will suggest many cases where constraint
    is unnecessary boilerplate. But there are other situations where
    it's useful.

    > > with Perl than with Python and since there is no way of forcing

    >
    > I'm always uncomfortable about trying to "force" a programmer
    > to do it a certain way.
    > [...]
    > to believe that trying to force programmers rather than inform
    > them is a good idea.


    Yeah, IMHO, the Python way is to *suggest*, not *force*. I generally
    would consider it good style to provide test code that the application
    programmer can use to check out their classes during development.

    Of course, one of the points of this is that Python *does* provide
    these abilities, in contrast to what the OP said. They may not look
    quite like they do in Java, and they may not seem as "tough". But,
    IMHO, they are "tough enough".

    --
    Terry Hancock ( hancock at anansispaceworks.com )
    Anansi Spaceworks http://www.anansispaceworks.com
    Terry Hancock, Jun 27, 2005
    #5
  6. Uwe Mayer

    ABO Guest

    > Okay. This makes sense if the software is:
    >
    > 1) Designed by one institution.
    > 2) Designed almost entirely before deployment.
    > 3) Not designed to be worked on by users and
    > semi-trained developers.
    >
    > In other words --- proprietary software.


    In my experience, it doesn't work well even in these cases. Investing a
    huge amount of effort designing in detail well in advance is nearly
    always a mistake, unless the requirements are fully understood and
    static... ie never.

    Mostly the requirements are unknown until the (possibly internal)
    customer has something. Nothing identifies requirements better than
    deployment. Particularly with large projects that have long development
    times, even if the requirements are well understood at the start, they
    will have changed by the time it is deployed.

    The biggest and most common mistake with software development is
    believing that it finishes. Software has a lifecycle, and development
    is like food; it is constantly required, otherwise the software dies.

    --
    Donovan Baarda
    ABO, Jun 30, 2005
    #6
    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. Replies:
    0
    Views:
    320
  2. Andrew Trevorrow

    Life + Python = Golly

    Andrew Trevorrow, Jun 25, 2006, in forum: Python
    Replies:
    1
    Views:
    369
    Michel Claveau
    Jun 25, 2006
  3. filippo

    OO on python real life tutorial?

    filippo, Sep 1, 2006, in forum: Python
    Replies:
    13
    Views:
    529
  4. Sebastian Bassi
    Replies:
    0
    Views:
    263
    Sebastian Bassi
    Nov 30, 2007
  5. Lawson English
    Replies:
    0
    Views:
    309
    Lawson English
    Jun 28, 2008
Loading...

Share This Page