Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Life of Python

Reply
Thread Tools

Life of Python

 
 
Uwe Mayer
Guest
Posts: n/a
 
      06-25-2005
Hi,

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

http://mail.python.org/pipermail/pyt...ly/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
 
Reply With Quote
 
 
 
 
Benji York
Guest
Posts: n/a
 
      06-25-2005
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
 
Reply With Quote
 
 
 
 
Chris Lambacher
Guest
Posts: n/a
 
      06-26-2005
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-i...on-either.html
http://naeblis.cx/rtomayko/2004/12/1...c-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 <(E-Mail Removed)> 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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Alan Gauld
Guest
Posts: n/a
 
      06-27-2005

"Uwe Mayer" <(E-Mail Removed)> wrote in message
news:d9jcij$nm6$(E-Mail Removed)-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


 
Reply With Quote
 
Terry Hancock
Guest
Posts: n/a
 
      06-27-2005
On Monday 27 June 2005 02:34 am, Alan Gauld wrote:
> "Uwe Mayer" <(E-Mail Removed)> wrote in message
> news:d9jcij$nm6$(E-Mail Removed)-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

 
Reply With Quote
 
ABO
Guest
Posts: n/a
 
      06-30-2005
> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Life Balance Coaching: Balance Work And Life Like A Pro 88059355 Digital Photography 1 01-06-2008 07:32 PM
The Nature Of Life As Seen From Earth - Life Energy Particles - Perception At A Distance {HRI 20010829-pi9-V2.0} - (part issue 9 Version 2.0 on 21 Aug 2005) Koos Nolst Trenite DVD Video 1 08-28-2005 09:23 AM
Have trouble in your life? Having the best time in your life? psion Computer Support 11 05-18-2004 06:51 AM
Flash memory udeful life and data storage life jriegle Digital Photography 0 10-16-2003 11:07 PM



Advertisments