Use global, or not

[DL Neil]

On 29/06/19 11:42 PM, Cecil Westerhof wrote:
> DL Neil <PythonList at 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