global, globals(), _global ?
no-spam at no-spam-no-spam.com
Wed Mar 15 12:02:45 EST 2006
Alex Martelli wrote:
> robert <no-spam at no-spam-no-spam.com> 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.
> 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
_f_ns.w = v+arg
print w # :-) ?
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