organizing your scripts, with plenty of re-use

[Stef Mientki]

Stephen Hansen wrote:
>
>
> On Mon, Oct 12, 2009 at 4:15 PM, Stef Mientki <stef.mientki at gmail.com 
> <mailto: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.
I agree it's difficult at the start, but after that,
you can create a new script / module everywhere you like ( within the 
projects), and every module is available,
and you can use (almost) any file as a self running program or as a 
library module.
>
> 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.
Well I missed that, I can't see the "higher" meaning of packages,
so if someone has a good link that explains the "higher" meaning of 
packages,
I'ld be much obliged.
>
> 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.
No, that's like tearing a page from a book and gluing it in another book
and the story get's
So the difference in my reasoning might be a mis-concept of the largest 
atomic part, which in my view is a class / function.
>
> 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.
Well I'm completely lost now, but that's probably because I'm not a 
programmer,
and I don't know the exact meaning of these words.
So I don't see a class as an object, just as a definition of 
"functionality".
A module, a file, a package, a directory (with it's subdirectories) is 
just a collector for classes.
I can freely move a class around within any of these containers without 
affecting the functionality of that class or anything that really uses 
that class.

>
> 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.
yes that's about the view I've now.
>
> 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.
>
I would love to hear one (and preferable more ;-) feature that a package 
adds to a collection of classes.

cheers,
Stef

> HTH,
>
> --S