By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,908 Members | 1,850 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,908 IT Pros & Developers. It's quick & easy.

Life of Python

P: n/a
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
Jul 19 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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
Jul 19 '05 #2

P: n/a
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 <be***@benjiyork.com> 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
la******@computer.org
Jul 19 '05 #3

P: n/a

"Uwe Mayer" <me*****@hadiko.de> wrote in message
news:d9**********@news2.rz.uni-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
Jul 19 '05 #4

P: n/a
On Monday 27 June 2005 02:34 am, Alan Gauld wrote:
"Uwe Mayer" <me*****@hadiko.de> wrote in message
news:d9**********@news2.rz.uni-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

Jul 19 '05 #5

P: n/a
ABO
> 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

Jul 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.