On Monday, November 11, 2013 8:47:09 PM UTC-6, Tim Daneliuk wrote: > I think this is certainly the use case most people would > suggest. But I think you may have missed the real reason > most modern designers object to inter-module globals: The > presence of such entities almost always means the code has > been designed badly. Whether we're writing pristine OO > code (cough, cough) or more traditional procedural stuff, > information hiding is a good thing.
Yes, and i agree. But you cannot "hide" everything. There will always be a need to share information. > When and where there is a need for modules (or programs, > or machines, or "clouds", or interstellar space ...) to > share information, my view is this is better done via some > sort of interface/message passing mechanism. But python modules can't be interfaces because interfaces should protect internal data, prevent external forces from meddling with internal state (EXCEPT via the rules of a predefined "contract"), hide dirty details from the caller, and have clearly defined access points. BUT PYTHON MODULES DON'T FOLLOW THIS DESIGN PATTERN! No, Python modules can be poked, prodded, and violated by any pervert who can spell the word "import". Attribute values can be reassigned and state can be externally manipulated resulting in all types of undefined behaviors -- that does not sound like an interface to me. So if python modules are importable everywhere, and mutable from everywhere, then python modules are merely addresses to a collection of global variables? And they're only interfaces "superficially"? So that leaves us with Python's current implementation of unofficial "global" variables implemented as "puesdo- interfaces" by module objects that are victims waiting to be violated. Interesting. IF IT WALKS LIKE A GLOBAL DUCK AND... -- https://mail.python.org/mailman/listinfo/python-list
