John Dann a écrit :
Many thanks for the repsonse - much appreciated.
And sorry - yes I was probably compounding two separate issues here -
the GUI one and the variable scope one. Maybe the wxPython list would
be the best place to ask more about the GUI side of things.
Then actually I can simplify my remaining question quite a lot - I
know you've partly answered this already but let me just rephrase
this:
It must be commonplace to first use a variable or object
What difference do you make between a variable and an object in this
context ?
within one
function in a module and then want to use it again - perhaps still
with the same value
For which definition of "same value" ? Remember, Python has *no*
primitive types. Everything is an object.
as in the first function - in a second function.
So what's the recommended Python way round this?
This is way too general to give a single straight answer - whatever the
language FWIW. Are both function in the same module ? Are they methods
of a same object ? Is the first function calling the second or are they
totally unrelated ?
If I was using .Net
then I'd be declaring the variables/objects explicitly
I personnally find the assignment, import, class and def statements (all
having a binding behaviour) to be rather explicit.
and could set
their scope according to how/where they were declared.
Names bound at the top-level are globals to the module. Names bound
within a function (including arguments) are locals, unless there has
been a global statement for them before in the same function's body.
Names bound within a class statement lives in the class's namespace (IOW
: they become class attributes, shared by all instances). And names
bound as object attributes (using either obj.name = whatever or
setattr(obj, "name", whatever)) become, well, object attributes.
Now there may be a couple points worth paying attention to :
1/ some types (numerics, strings and tuples at least) are immutable.
When doing :
i = 1
i = 2
the second assignment doesnt mutate the integer object bound to i, but
rebinds i to another integer object.
2/ the scope of a name isn't necessarily related to the scope of the
object bound to that name.
As an example, function's parameters *names* are local to the function,
but the actual arguments - the objects passed when calling the function
- are not.
IOW, rebinding a parameter name withing a function body will rebind the
name locally, but will not affect the object originally bound to that
name. But *mutating* an object passed as argument *will* (off course)
affect the object outside the function.
But if the
Python way is not to declare vars before use
For which definition of "var" and "use" ? Did you really try to use a
name that didn't exist in the accessible namespace - I mean, "use" for
anything else than binding ?
The first binding of a name in a namespace *is* the 'declaration'. If a
name is not defined in the currently accessible namespace, and you try
to do anything else than binding it, you'll get an exception.
then this must create
some problems for cross-function use.
If what you mean is that it makes it harder to litter you code with true
global variables, then it's obviously a *very* good thing IMHO !-)
But no, there's no more problem with shared state in Python than in any
other (imperative) language I know - usually less in fact since there's
no "application global" namespace. Most of the time, the appropriate way
to share state is to use classes - heck, that's what they were created
for, isn't it ?-). Sharing state thru module-level variables is ok as
long you only access it for reading (pseudo-constants etc).
Sometimes, it's ok to use a module-level variable read-write, but this
should be restricted to this particular module's implementation stuff
(IOW : the name is not part of the API, and only functions / methods in
this same module access it), and never done without a clear enough
understanding of Python's namespaces and bindings.
So it is best to declare such vars at the module level (ie outside of
a function) and set eg to Null/None or to assign them with a keyword
such as global or static (assuming that concept applies in Python)
it doesnt.
at first use inside a function or what?
Usually, when you really need a module-level variable to be shared
read-write between functions, it happens that you can bind it to a
sensible default. Now what is a "sensible default" depends on the
concrete use case. Anyway, by all means, explicitely bind this name at
the top-level, before any code accessing it, and if possible with a
comment about this name being shared read/write by functions x and y.
My 2 cents...
--
http://mail.python.org/mailman/listinfo/python-list
