organizing your scripts, with plenty of re-use
Stef Mientki
stef.mientki at gmail.com
Tue Oct 13 16:33:20 EDT 2009
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
More information about the Python-list
mailing list