getting equal behavior for scripts and modules ?
stef.mientki at gmail.com
Sun Oct 11 23:07:30 CEST 2009
Gabriel Genellina wrote:
> En Sun, 11 Oct 2009 14:50:31 -0300, Stef Mientki
> <stef.mientki at gmail.com> escribió:
>> I do agree that circular references should preferable be avoided.
>> In languages like Delphi, you get an error message, trying to use
>> circular references,
>> but solving them in large programs with a lot of history can be very
>> Now I finally (after 2 years) knowing there's a difference between
>> modules and scripts,
>> I want to guarantee that I always get the same functional behavior.
> In Delphi terms, you have units (.pas) and programs (.dpr). You can't
> add a .dpr to the Uses clause of an unit. In case you have some code
> in a .dpr that you want to use somewhere else, you move it into a new
> unit and Use it from both places.
I never ever edited a dpr file, it's created fully automatically (don't
know what is in it) and I even think you don't need to use it at all.
In Delphi there's a "main unit" and other units, but it's up to the
programmer which unit is set as the "main unit".
Although I admit (because of the forbidden circular references) that's
not easy to use a unit designed as "main", and use as normal unit or
even better as a general purpose library.
> Translated to Python terms: you have modules and scripts. You
> shouldn't import a script from a module. In case you have some code in
> a script that you want to use somewhere else, move it into a new
> module and import it from both places.
> Note the change between "can't" and "shouldn't". Delphi just won't let
> you import the main program from another place;
well is does, notice Delphi has 2 locations for the uses clause !
> Python does, with strange effects, but you should not do that. You can
> avoid the temptation by naming your scripts with another extension (or
> no extension at all).
Going from Delphi to Python,
using a module (unit) both as standalone program and a library for other
was a beautiful relief.
Now finally I could play with software as if it was Lego ( those
children building blocks).
And indeed I've a few stand alone Python applications, that can fully be
embedded in other Python applications and docked in their GUI.
>> I found 2 solutions to realize the above.
> Too much hassle and magic for what should be a non-issue.
If you choose for a strict separation between "script" and "module", I
guess it's indeed a non-issue.
Using software as if it was Lego, needs either a detection or prevention
of effects of the difference between script and module.
More information about the Python-list