global, globals(), _global ?

robert no-spam at
Wed Mar 15 18:02:45 CET 2006

Alex Martelli wrote:

> robert <no-spam at> wrote:
>    ...
>>( 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;
> 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.

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.zop= , 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 ..

>>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.
> 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

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

Module Net
  class String

> 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?

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():
     def _(arg):
         _f_ns.w = v+arg
     print v
     print w  # :-) ?

def g(_):

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 


More information about the Python-list mailing list