organizing your scripts, with plenty of re-use

Stephen Hansen apt.shansen at gmail.com
Tue Oct 13 07:00:58 CEST 2009


On Mon, Oct 12, 2009 at 4:15 PM, Stef Mientki <stef.mientki at gmail.com>wrote:

> Hierarchical choices are done on todays knowledge, tomorrow we might have
> different views and want/need to arrange things in another way.
> An otter may become a reptile ;-)
> So from the human viewpoint the following should be possible (and is for
> example possible in Delphi)
> - I can move the complete project anywhere I like and it should still work
> without any modifications (when I move my desk I can still do my work)
>

This is readily doable in Python; in fact it should just work. You only need
to ensure where you move it ends up in the PYTHONPATH-- but that'll take at
most just one change, once. You can use batch scripts to alter it if you
really need to, but that's all you would need to do.


> - I can move any file in he project to any other place in the project and
> again everything should work without any modifications ( when I rearrange my
> books, I can still find a specific book)
>
> In my humble opinion if these actions are not possible, there must be
> redundant information in the collection. The only valid reason for redundant
> information is to perform self healing (or call it error correction), and
> here we have a catch-22.
>

This is the problem; this is just incorrect thinking and if one's
programming in Python needs to be excised. Things don't work like that, and
trying to make it work like that will result in you going against the grain
of /how/ Python works, and life will become difficult.

Packages are meaningful in Python. They aren't just directories which you're
organizing for your human-programmer's convenience and understanding. They
are a fundamental structure of objects and must be treated as such.

Python doesn't think in terms of files. You can't just move files around
within a project because that's a semantically significant change.

It's just like you can't move a method on a class to another class, and
expect everything to just work.

A package is just like a class, its a significant, structural component in
the code itself. It contains files, but those files aren't what's
significant to Python-- what's significant is that they are modules, which
are also just like a class. They're objects which contain other objects.

Every package creates a namespace of objects it contains; those objects are
modules (and other things that may be defined in __init__.py). Every module
creates a namespace of objects it contains. Classes create a namespace of
objects they contain.

These are all objects. A package isn't a directory you're organizing -- its
an object which contains other objects.

If you try to change this so that there's no object organization of an
object hierarchy, then you're going to create significant issues for
maintenance and have to jump through all kinds of hoops to try to accomplish
it. It sounds like you want a system where each file is a unique module, and
its particular location isn't important-- the filename creates a unique
identity, a top-level namespace which can be accessed from anywhere.

Python's object model just doesn't work like that. There's nothing wrong
with how Python works in this regard, its simply different, and if you try
to program Delphi in Python, you'll run into lots of problems. Just like if
you try to program Java or C in Python. They're different languages with
different object models, and you have to adapt to the object model of the
language if you want to use the language effectively.

HTH,

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20091012/9cdcbc2e/attachment.html>


More information about the Python-list mailing list