[wingide-users] global imports
georgex.mclam at intel.com
Wed Jun 8 15:22:27 MDT 2011
Thank you for the reply.
> I *think* what you are doing is using a single consistent Subroutines module,
> where the subroutines depend on a large number of parameters, and the specific
> set of parameters are to be selected by the particular main module for a
> particular project.
YES! EXACTLY! :)
> Yet you say: "Subroutines has no clue of what it importing...."
> I am taking this to mean that Subroutines ought not to be hard-coded as to *which*
> particular parameters modules it's importing,
Also correct because each project has its own parameters / parameter files.
> BUT presumably within the individual subroutines it knows the names of all the
> individual parameter variables (functions or whatever) in order to be able to call
> them, right?
Not usually. It gets really deep really fast and I was trying to avoid getting into
so much detail. There are literally dozens of functions inside subroutines, each with
it's own flavor. Sometimes a function name is passed. Sometimes it is passed as a
string, in which case subroutines needs to do an eval() on it to determine the
function address. Sometimes subroutines "calculates" a function name. There are a
lot more scenarios than I can really get into, so all I can say is that subroutines
needs the parameter data on its own and cannot rely on it all being passed.
I considered the idea of having each function perform imports but that is crazy too.
> Instead of using relatively advanced Python to fiddle with the list of globals,
> why not revise each param file into an object, ...?
Lots of work, if it works.
Longer story ... I created a library of code to run automation. There are modules
for different devices and parameters to make those devices work, and then there are
test parameters. A typical test setup for automation could easily take 10, 20 or
more files. The main application module knows what tests are being performed and
does the orchestration of loading all the parameters for its job. But when it comes
time to do the heavy lifting, it calls a function in subroutines. Sometimes the number
of parameters that would need to be passed by main to a single function in subroutines
easily exceeds 100 and is likely a LOT more.
Presently it all works because I have a copy of subroutines that merely imports the
set of files needed for a project/test. The ONLY thing different between ALL of the
copies of subroutines I have is the import statements at the top. VERY SILLY. LOL,
even sillier me for thinking I could just "set" those module names once from main
so that a single subroutines file could exist for all projects and tests.
The issue is not with the "import" per se, it is figuring out a way to make what is
"imported" global to the entire MODULE (subroutines) without having to go through
a list of each object, name by name, that is being imported. That is a lot more
coding and will very likely create errors where they presently do not exist. Also,
as new projects and tests are added, more objects will be added that have not even
been dreamed of yet.
While the idea of "global means local" by Python creators looks good on paper,
it is a nightmare for lots of applications.
From: wingide-users-bounces at wingware.com [mailto:wingide-users-bounces at wingware.com] On Behalf Of Graham Wideman
Sent: Wednesday, June 08, 2011 1:22 PM
To: wingide-users at wingware.com
Subject: RE: [wingide-users] global imports
I am not completely clear what you are trying to achieve, but will take a crack at it.
I *think* what you are doing is using a single consistent Subroutines module, where the subroutines depend on a large number of parameters, and the specific set of parameters are to be selected by the particular main module for a particular project.
Yet you say: "Subroutines has no clue of what it importing...."
I am taking this to mean that Subroutines ought not to be hard-coded as to *which* particular parameters modules it's importing, BUT presumably within the individual subroutines it knows the names of all the individual parameter variables (functions or whatever) in order to be able to call them, right? Ie: The names of the individual param variables are at least consistent across different versions of a parameter file, right?
Anyhow, assuming that is on track...
Instead of using relatively advanced Python to fiddle with the list of globals, why not revise each param file into an object, so that the entire set of variables (or functions or whatever) in that param file can be referenced through a single object variable.
Then you can use main as the single place where you import the particular set of say three param files for that project, and either assign them to three global variables in Subroutines, or pass them to an init routine in Subroutines which assigns them to module globals.
Within Subroutines, you would need to prefix each use of a param variable with the name of the applicable module global, but that's a one-time edit, and makes it very clear where each value is coming from (Ie: I'm advocating this as an improvement over just having loads of individual globals).
Wing IDE users list
More information about the wingide-users