On 29/06/19 11:42 PM, Cecil Westerhof wrote:
DL Neil <pythonl...@danceswithmice.info> writes:
On 29/06/19 1:44 AM, Cecil Westerhof wrote:
I have written a GUI program where I have quit a few global variables.
I did not like this, so I now use one global dict. Something like:
global global_dict
...
Is that an acceptable way to do this?
If it works, isn't that the largest part of "acceptable"?
Depends on your way of thinking. ;-)
You detected that I had my tongue firmly stuck in my cheek!
I think it is always best when you write in a language to do it in
that languages way. In this case Python.
I also think this is a program that could be interesting to share.
Then it becomes even more important to do it the Python way.
And my experience is that when asking this type of question you often
get a tip that helps you make your program better.
Here's hoping that you have/will!
Speaking personally, I avoid using "global". Earlier, the topic of
"namespaces" was broached. The danger of nesting one namespace inside
another is that the local scope may (accidentally) override THE name, or
that one forgets the "global variable_name" line-of-code. Added to
which, are OOP virtues which talk about separation and encapsulation, etc...
The pythonic way includes contentions:
1 There should be one-- and preferably only one --obvious way to do it.
- although you might not like the next line, until it is understood to
be a joke at Guido's expense...
2 "we are all adults here".
In each case, (previously discussed and/or below) you are taking
advantage of "namespaces" to keep one 'lot' of values separated and
distinct from others - as well as finding a means of 'passing them
around'. The other half of the considerations is how the values are
being retrieved/utilised within the mainline code.
An alternative might be to use a class. Then accessing a single value
becomes instance.attribute, but when you have need for several
attribute's values or to compute a value from several attributes, an
instance.method() may simplify things.
That was the other possibility I was thinking about. And that would be
maybe better. Because I now do things like:
global_dict['messages']['created'].format(len(filepathArr))
much better would be:
instance.created(len(filepathArr))
+1
Scanning my projects directory, there seems to be quite a mix of classes
and modules to handle this situation. ("one way"..."obvious"???)
The last example might recommend an investigation of "property". I'm
slightly reluctant to suggest this to someone coming from another, more
structured, language, eg Java, because it is so easy to make a
literal-translation between languages and (as you have said) miss a
pythonic advantage, eg direct access to instance.attribute (cf the need
to code "getters", such as "instance.get_attribute()").
Most (Python) "property" tutorials seem to center on attempts to
reproduce "private variables". (you can't really/easily and (again)
aren't we "all adults...") However, I like using @property whenever
there is some computation-required involving attributes, eg
class name():
...
@property
def filepath_length( self ):
return len( filepath_arr )
...
instance.filepath_length
Again, speaking personally, the advantages relate to readability and
separation of concerns (I'd like the answer delivered, not the need to
compute something which the object should do as part of 'itself' - IMHO)
Warning: there's a few statements and opinions 'here' which others may
care to argue - and like you I'm happy to (hope to) learn something
useful...
Refs:
The "Zen of Python": start python and import this
https://docs.python.org/3.6/howto/descriptor.html?highlight=property
https://docs.python.org/3.6/library/functions.html?highlight=property#property
https://docs.python.org/3.6/tutorial/classes.html
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
