global, globals(), _global ?

[robert]

Using global variables in Python often raises chaos. Other languages use
a clear prefix for globals.

* you forget to declare a global
* or you declare a global too much or in conflict
* you have a local identical variable name and want to save/load it
to/from the global with same name
* while you add code, the definition of globals moves more and more
apart from their use cases -> weirdness; programmers thinking is fragmented
* using globals()['xy'] is 'stringy non-program-code'


Thus, since long time at the head of my bigger modules I often put...

_global = sys.modules[__name__]

....and use global variables only/mainly like

def f(y):
v=x=_global.x
_global.y=y
...

for me this method is much more clear overall. And it is in line with
the clear exposition of "self" as regular object in Python methods (in a
much more self-similiar way compared to frozen @ $ m_... hacks in other
languages)

I know, this home created _global creates a circular ref, but usually
this is not serious as modules are unload only at the end of a program.

( side question: does this maybe hinder global objects from being
__del__'ed correctly; is at least gc() run when all modules are pulled
off at exit() )

Somehow I miss a nice standard method for using globals in an
unfragmented way everywhere. What do you think?

Robert

[Xaver Hinterhuber]

Re: global, globals(), _global ?

Hi Robert,

I was using global variables some time ago, too.
But with the time the program simply got unmaintainable, because it is very
hard
to trace, why a global variable has some special value and not the one, you
thought it should have.
So I redesigned the program and now I can do it without global variables.

To me global variables are now in most cases a sign of bad design.
Is there no other way to do it?

Greets

Xaver

"robert" <no-spam@no-spam-no-spam.com> schrieb im Newsbeitrag
news:dv8oqe$1cb n$1@ulysses.new s.tiscali.de...[color=blue]
> Using global variables in Python often raises chaos. Other languages use a
> clear prefix for globals.
>
> * you forget to declare a global
> * or you declare a global too much or in conflict
> * you have a local identical variable name and want to save/load it
> to/from the global with same name
> * while you add code, the definition of globals moves more and more apart
> from their use cases -> weirdness; programmers thinking is fragmented
> * using globals()['xy'] is 'stringy non-program-code'
>
>
> Thus, since long time at the head of my bigger modules I often put...
>
> _global = sys.modules[__name__]
>
> ...and use global variables only/mainly like
>
> def f(y):
> v=x=_global.x
> _global.y=y
> ...
>
> for me this method is much more clear overall. And it is in line with the
> clear exposition of "self" as regular object in Python methods (in a much
> more self-similiar way compared to frozen @ $ m_... hacks in other
> languages)
>
> I know, this home created _global creates a circular ref, but usually this
> is not serious as modules are unload only at the end of a program.
>
> ( side question: does this maybe hinder global objects from being
> __del__'ed correctly; is at least gc() run when all modules are pulled off
> at exit() )
>
> Somehow I miss a nice standard method for using globals in an unfragmented
> way everywhere. What do you think?
>
> Robert[/color]

[robert]

Re: global, globals(), _global ?

Xaver Hinterhuber wrote:
[color=blue]
> Hi Robert,
>
> I was using global variables some time ago, too.
> But with the time the program simply got unmaintainable, because it is very
> hard
> to trace, why a global variable has some special value and not the one, you
> thought it should have.
> So I redesigned the program and now I can do it without global variables.
>
> To me global variables are now in most cases a sign of bad design.
> Is there no other way to do it?[/color]

Yes, one should put common _application_ variables of importance to
config instances or data-modules/classes etc.

Yet globals variables in Python are anyway "module commons". That is a
frequent practical need.

Grep e.g. the python standard modules for use of global variables and
use of "global "

There are many practical module globals, which control e.g. the mode of
a module, store precomputed/cached stuff etc., and where you do not open
an extra data structure (for now).

Most variable read-s in Python anyway go to module globals - as there
are no other kinds of namespaces except __builtins__

( And that later scheme is fairly wonderful - compare for example the
namespace fuzz in C/C++, Pascal, Ruby, ... where you never know which
module file addeds what to which namespace;

In Ruby they even scribble from anywhere to _any_ class _and_ any
namespace without the barrier of a dot or subclassing or anything -
using somehow by random the same name already joins!? A threat for good
modularization of code. Not far from free flat memory programming :-)
Don't know how they keep bigger projects managable in this language.
)


Yet, python module globals are set with this strange fragmented "global
name ; name=..".

But the common storage object in question is an ordinary module anyway.
Why not stay self-similiar and use it as such in dot-syntax for write-s
(and often for read-s in places, where you want to express the use of a
special global explicitly in order to not confuse things with locals,
and want to maintain the code readable.

Robert

[Fredrik Lundh]

Re: global, globals(), _global ?

"robert" wrote:
[color=blue]
> Most variable read-s in Python anyway go to module globals - as there
> are no other kinds of namespaces except __builtins__[/color]

your post made some sense until I got to this paragraph, which appears to
completely ignore local variables, arguments, and variables in intermediate
scopes ? maybe you could clarify ?

</F>

[Roy Smith]

Re: global, globals(), _global ?

In article <dv8oqe$1cbn$1@ ulysses.news.ti scali.de>,
robert <no-spam@no-spam-no-spam.com> wrote:
[color=blue]
> Using global variables in Python often raises chaos. Other languages use
> a clear prefix for globals.[/color]

Unsing globals raises chaos in any language. They should be shunned and
avoided.

[Daniel Dittmar]

Re: global, globals(), _global ?

Roy Smith wrote:[color=blue]
> In article <dv8oqe$1cbn$1@ ulysses.news.ti scali.de>,
> robert <no-spam@no-spam-no-spam.com> wrote:
>[color=green]
>> Using global variables in Python often raises chaos. Other languages use
>> a clear prefix for globals.[/color]
>
> Unsing globals raises chaos in any language. They should be shunned and
> avoided.[/color]

Solution: replace globals with Singletons ;-)

Daniel

[robert]

Re: global, globals(), _global ?

Fredrik Lundh wrote:
[color=blue]
> "robert" wrote:
>
>[color=green]
>>Most variable read-s in Python anyway go to module globals - as there
>>are no other kinds of namespaces except __builtins__[/color]
>
>
> your post made some sense until I got to this paragraph, which appears to
> completely ignore local variables, arguments, and variables in intermediate
> scopes ? maybe you could clarify ?[/color]

Of course the local namespaces on the stack are the unmentioned default
(the intermediate frames are half way on the stack ..).

The discussion focused on off-stack, "common" name spaces. Python has
done the right magic in order to let modularize code well.

Just self-similiar self-inspection is not (yet) done to the best in some
places: this "_global" own module, self inspection in
functions/classes/methods (nameless recursion), stack handling/callcc

Robert

[Alex Martelli]

Re: global, globals(), _global ?

robert <no-spam@no-spam-no-spam.com> wrote:
...[color=blue]
> ( And that later scheme is fairly wonderful - compare for example the
> namespace fuzz in C/C++, Pascal, Ruby, ... where you never know which
> module file addeds what to which namespace;[/color]

Pascal (per se) doesn't really have much by the way of namespaces
(alas). C++ (per se) does, with zap::zop=23 being rather unambiguous (C
compatibility and "using namespace zap" can muddy it up, but that's like
saying, e.g., that "from zap import *" muddies things up in Python:
true, but the obvious solution in both cases is "just don't do it";-).

Sure, any C++ or Ruby soure file can reopen a namespace or class,
respectifely -- but how's that different from Python's
"anothermodule. zop=23"? It's much of a muchness.

[color=blue]
> In Ruby they even scribble from anywhere to _any_ class _and_ any
> namespace without the barrier of a dot or subclassing or anything -
> using somehow by random the same name already joins!? A threat for good
> modularization of code. Not far from free flat memory programming :-)
> Don't know how they keep bigger projects managable in this language.[/color]

Uh? I don't see what you mean -- in Ruby, an assignment can be clearly
situated regarding what namespace it affects. The only example of
"using somehow by random the same name" I can think of is within a
block, where (e.g.) 'a=2' sets a new block-local name _unless_ 'a' was
previously used within the lexically enclosing method, in which case it
resets said method's 'a', but while unpleasant that's a fairly localized
problem. Maybe you can give some examples?


Alex

[Alex Martelli]

Re: global, globals(), _global ?

robert <no-spam@no-spam-no-spam.com> wrote:
[color=blue]
> Using global variables in Python often raises chaos. Other languages use
> a clear prefix for globals.[/color]

Ruby does ($ means global), but, what other languages? Perl, C, C++,
Java (taking a class's statics as Java's equivalent of other languages'
globals), etc, etc, all use the same lexical form for identifiers
whether local or global, disambiguating in other ways, not by "a clear
prefix" ('my' in Perl to declare locals, sort of like 'global' in Python
to declare globals, just with the default the other way 'round, etc).
Can you please explain what you mean here?

Anyway, I'd LOVE expunging the hated 'global' in favour of an explicit
namespace (and another one for "free variables in containing functions"
for closures), but while this gets often proposed in python-dev, Guido
is apparently never going to approve such a change (even in Py3k where
backwards compatibility could be broken), so I've given up on it.


Alex

[robert]

Re: global, globals(), _global ?

Alex Martelli wrote:
[color=blue]
> robert <no-spam@no-spam-no-spam.com> wrote:
> ...
>[color=green]
>>( And that later scheme is fairly wonderful - compare for example the
>>namespace fuzz in C/C++, Pascal, Ruby, ... where you never know which
>>module file addeds what to which namespace;[/color]
>
> Pascal (per se) doesn't really have much by the way of namespaces
> (alas). C++ (per se) does, with zap::zop=23 being rather unambiguous (C
> compatibility and "using namespace zap" can muddy it up, but that's like
> saying, e.g., that "from zap import *" muddies things up in Python:
> true, but the obvious solution in both cases is "just don't do it";-).
>
> Sure, any C++ or Ruby soure file can reopen a namespace or class,
> respectifely -- but how's that different from Python's
> "anothermodule. zop=23"? It's much of a muchness.[/color]

In Python the module name _is_ the namespace and _is_ the filename. In
C++/Ruby it is not.

And the namescapes in Python are accessed as local as necessary and as
any object (Import in a funtion). This self-similarity enables best
modularization of code.

If you write anothermodule.z op= , this is a daylight-attack to exactly
the module which you just _imported_ in local context and use the
..-operator on. In "namespace" languages you write something randomly ..
[color=blue][color=green]
>>In Ruby they even scribble from anywhere to _any_ class _and_ any
>>namespace without the barrier of a dot or subclassing or anything -
>>using somehow by random the same name already joins!? A threat for good
>>modularizatio n of code. Not far from free flat memory programming :-)
>>Don't know how they keep bigger projects managable in this language.[/color]
>
> Uh? I don't see what you mean -- in Ruby, an assignment can be clearly
> situated regarding what namespace it affects. The only example of
> "using somehow by random the same name" I can think of is within a[/color]

You must know _all_ Ruby Module & Class names I think - in any file.
Start writing:

Module Net
...
class String
....
[color=blue]
> block, where (e.g.) 'a=2' sets a new block-local name _unless_ 'a' was
> previously used within the lexically enclosing method, in which case it
> resets said method's 'a', but while unpleasant that's a fairly localized
> problem. Maybe you can give some examples?[/color]

about that later I cannot say if its worse or better than in Python.
Python only reads from enclosing frames. If you want to write down you
need a container. Python is more restricted but clear in this.

Ruby people often, say their blocks replace generators in the "Ruby way" :-)

Blocks are infact only Python callbacks like

def f():
v=w=7
_f_ns=X()
def _(arg):
_f_ns.w = v+arg
g(_)
print v
print w # :-) ?

def g(_):
_(7)


Iterators/Generators, which _delay_ execution, are not possible easily
in Ruby ( unless you fiddle something with callcc )

If Python would enable somehow self-inspectional write access (X) to its
local frames, it maybe would have even better "blocks" - same as with
_global


Robert

[robert]

Re: global, globals(), _global ?

Alex Martelli wrote:
[color=blue]
> robert <no-spam@no-spam-no-spam.com> wrote:
>
>[color=green]
>>Using global variables in Python often raises chaos. Other languages use
>>a clear prefix for globals.[/color]
>
> Ruby does ($ means global), but, what other languages? Perl, C, C++,
> Java (taking a class's statics as Java's equivalent of other languages'
> globals), etc, etc, all use the same lexical form for identifiers
> whether local or global, disambiguating in other ways, not by "a clear
> prefix" ('my' in Perl to declare locals, sort of like 'global' in Python
> to declare globals, just with the default the other way 'round, etc).
> Can you please explain what you mean here?[/color]

I though first of Ruby.

Good C++ code uses m_ , g_ for members, globals, ... e.g. the
Microsoft MFC code ( you have to declare the vars anyway - and it is
compiler checked unlike in dict-languages ), :: for global namespace.

In Scheme like:

(global-set! SYMBOL X)
(set! (global-ref SYMBOL) X)

Python has taken the 'global' statement from TCL,PHP,.. which are a
namespace languages. That was unnecessary - as Python modules are
already real objects.

[color=blue]
> Anyway, I'd LOVE expunging the hated 'global' in favour of an explicit
> namespace (and another one for "free variables in containing functions"
> for closures), but while this gets often proposed in python-dev, Guido
> is apparently never going to approve such a change (even in Py3k where
> backwards compatibility could be broken), so I've given up on it.[/color]

If the _global virtual remains something like an object (which I'd
recommend), there is compatibility. if 'global' has to be dropped? or
just be moved to the end of the docs...

Opening the local namespace is difficult, because the global scope is
the default; only x= declares the local.

I think its good to leave the default global binding (that is probably
whats Guido doesn't want to give up for good reason)

Yet frames could expose their top-dict anyway as a virtual inspection
object (__l/__l_<funcname> or __f_stack[-2]) . Or at least writing to
locals() could be defined as writing to the top-frame-locals.
Sub-Frames could write free there (its a rare & conscious task anyway)
and the Frame itself could read either way.

---

Another ugly possibilties maybe by enriching variable assignment.

Maybe '=' can be enriched like .= ..= := =: ::= =:: xxx-set ... etc.
in order to be an expression with result value and to allow to writing
to certain namspaces.

Robert

[Duncan Booth]

Re: global, globals(), _global ?

robert wrote:
[color=blue]
> Good C++ code uses m_ , g_ for members, globals, ...[/color]

.... for some definition of 'Good'.

[Alex Martelli]

Re: global, globals(), _global ?

robert <no-spam@no-spam-no-spam.com> wrote:
...[color=blue][color=green]
> > Ruby does ($ means global), but, what other languages? Perl, C, C++,
> > Java (taking a class's statics as Java's equivalent of other languages'[/color][/color]
...[color=blue]
> I though first of Ruby.
>
> Good C++ code uses m_ , g_ for members, globals, ... e.g. the[/color]

_Some_ C++ code uses such guidelines, but I think you're assuming way
too much by implying that (all) good C++ code does that.

For example, the Google style guide (and I assure you we have a *LOT* of
C++ code, and it *IS* pretty good indeed) uses a different convention
(not a prefix) for instance variables, and no 'stropping' distinction
between locals and globals (even though I'm more into the Python side of
things, than the C++ side, I do work regularly at Google in both
languages, I passed my "readabilit y certification" for C++ as well as
Python, proving I know and apply the Google style rules very well, and
I'm very aware of the long exhaustive debates on which each language's
style guide is based and by which it keeps getting tweaked when needed).

Remember, for example, that part of what defines "good" C++ style (in a
firm developing lots of software in both C++ and Python) is the ease of
using SWIG (or other tool of choice, but Google prefers SWIG) to wrap
the C++ code so Python can use it too.

Anyway, guess we should move this particular discussion to a C++ forum,
and similarly for the Java one, the Perl one, and so forth. Let's leave
it at this: Ruby's the only language that mandates stropping for globals
(in any language you may choose to adopt such _conventions_, just like
you could choose, e.g., Hungarian notation -- silly, but possible;-).
[color=blue]
> Microsoft MFC code ( you have to declare the vars anyway - and it is[/color]

I've worked FAR too much with Microsoft's MFC (back when I was a Windows
and C++ guru, in the '90s) to accept their being claimed as an example
of "good C++ code" as anything but not-thinly-veiled sarcasm!

MS itself doesn't like the MFC any more, indeed they first tried
replacing it with the WTL before (essentially) giving up on C++ (the
main designer of C# was the same guy who earlier designed WTL;-) and
opensourcing WTL (IMHO still the best way to do Windows GUI in C++, if
you're condemned to such a worse-than-death task;-).
[color=blue]
> compiler checked unlike in dict-languages ), :: for global namespace.[/color]

"Per-module-global", though, is the unnamed namespace (used to be
'static', but that's deprecated at global scope nowadays)
[color=blue]
> I think its good to leave the default global binding (that is probably
> whats Guido doesn't want to give up for good reason)[/color]

Then, on the principle that there should be preferably only one obvious
way to do something, we'll never have an _global object as you propose
(even by any other and much better name;-), because it systematically
produces TWO equally obvious or unobvious way to access globals.
[color=blue]
> Yet frames could expose their top-dict anyway as a virtual inspection
> object (__l/__l_<funcname> or __f_stack[-2]) . Or at least writing to
> locals() could be defined as writing to the top-frame-locals.
> Sub-Frames could write free there (its a rare & conscious task anyway)
> and the Frame itself could read either way.[/color]

Not sure I entirely understand what you're proposing, but locals access
must remain compile-time-optimized for crucial practical reasons, so
"writing to locals()" just will not work right.
[color=blue]
> Another ugly possibilties maybe by enriching variable assignment.
>
> Maybe '=' can be enriched like .= ..= := =: ::= =:: xxx-set ... etc.
> in order to be an expression with result value and to allow to writing
> to certain namspaces.[/color]

Ugly enough that Guido has never wanted to entertain such possibilities
each of the many, many times they've been proposed on python-dev over
the years. python-dev is archived and easily searchable -- maybe you
can research the last few years of discussion there, assuming you're at
all interested in seeing your proposals implemented in Python.


Alex

[robert]

A Frame-space syntax ? - Re: global, globals(), _global ?

Alex Martelli wrote:[color=blue]
> robert <no-spam@no-spam-no-spam.com> wrote:
> ...[/color]
[color=blue][color=green]
>>I think its good to leave the default global binding (that is probably
>>whats Guido doesn't want to give up for good reason)[/color]
>
>
> Then, on the principle that there should be preferably only one obvious
> way to do something, we'll never have an _global object as you propose
> (even by any other and much better name;-), because it systematically
> produces TWO equally obvious or unobvious way to access globals.[/color]

a path to the globals whould maybe not much different from an alternate
__dict__ or globals() access. and see below ..
[color=blue][color=green]
>>Yet frames could expose their top-dict anyway as a virtual inspection
>>object (__l/__l_<funcname> or __f_stack[-2]) . Or at least writing to
>>locals() could be defined as writing to the top-frame-locals.
>>Sub-Frames could write free there (its a rare & conscious task anyway)
>>and the Frame itself could read either way.[/color]
>
>
> Not sure I entirely understand what you're proposing, but locals access
> must remain compile-time-optimized for crucial practical reasons, so
> "writing to locals()" just will not work right.[/color]

Why will a definite write to _certain_ top local dict consume any extra
time?
The target can still be directed fix at compile time. See below.
[color=blue][color=green]
>>Another ugly possibilties maybe by enriching variable assignment.
>>
>>Maybe '=' can be enriched like .= ..= := =: ::= =:: xxx-set ... etc.
>>in order to be an expression with result value and to allow to writing
>>to certain namspaces.[/color]
>
>
> Ugly enough that Guido has never wanted to entertain such possibilities[/color]

Maybe a syntax could be applied which is already known for float
litterals and which seems to be intuitive and compatible to me:

a=1
..a=1 # same
d=5
def f()
b=1
.b=1 # same
print a
print ..a # same
..a += 1 # compile-time known: its the global!
def g():
..b=2 # f-local b !
..c=3 # write a 'free local' into f-locals
..d=4
...a += 1 # the compiler knows: its global!
g()
print b # local
print 1 + .c # ok
print c # error!, but thats acceptable
print d # global
print .d # local!, but thats acceptable


This syntax shows some kind of self-similarity:
* a dot . always references a definite dict/namespace/obj (or a float)
* a free dot . simply references the top local dictionary (or a float)
* more dots step back through the frame stack
* If no dot is there the usual "automatic name space" is assumed

No old code would be broken.

As far as I see this would not slow down the interpreter at run time
(except maybe for the new "..b=" intermediate local write's)

Robert

[Alex Martelli]

Re: A Frame-space syntax ? - Re: global, globals(), _global ?

robert <no-spam@no-spam-no-spam.com> wrote:
...[color=blue][color=green]
> > Not sure I entirely understand what you're proposing, but locals access
> > must remain compile-time-optimized for crucial practical reasons, so
> > "writing to locals()" just will not work right.[/color]
>
> Why will a definite write to _certain_ top local dict consume any extra
> time?[/color]

Writing to a dict intrinsically takes longer than writing to a fixed
offset into a vector. locals(), as a dict, is in fact built as a shim
on top of the fixed vector where a function's locals are kept. We're
talking of a difference in timing of over a factor of two, over a
microsecond per local-variable access on my laptop -- the average
function does so much locals-accessing that I would expect it to slow
down proportionally, by a factor of two or so, if locals were actually
kept in a dictionary rather than in a vector.

Try it out by running the same code as a module's main body versus
running it as a function -- see how much the latter approach speeds
things up. Indeed, "put the code inside a function" is the first
optimization tip to give to any newbie, exactly because a module's
top-level code actually does read/write a dict for each variable access,
while a function's body code does not.
[color=blue]
> The target can still be directed fix at compile time. See below.[/color]

None of the examples you give below exemplifies "writing to
locals() could be defined as writing to the top-frame-locals" as you had
proposed in the snippet I was responding to.

[color=blue][color=green]
> > Ugly enough that Guido has never wanted to entertain such possibilities[/color]
>
> Maybe a syntax could be applied which is already known for float
> litterals and which seems to be intuitive and compatible to me:
>
> a=1
> .a=1 # same[/color]

Just about exactly this syntax was recently discussed on python-dev and
Guido (and many others) shot it down in no time. Please do take the tiny
trouble to research the python-dev archives, as I already suggested,
before proposing something that's so recently been roundly rejected.
[color=blue]
> As far as I see this would not slow down the interpreter at run time
> (except maybe for the new "..b=" intermediate local write's)[/color]

Each local access that goes to a dict instead of a fixed vector will
intrinsically and inevitably slow down by 2-3 times. And the fact that
sometimes accessing a local c is the same as accessing .c, and sometimes
it isn't, is something I'm *EXTREMELY* happy to not have to teach,
explain, and justify.


Alex