Alex Martelli wrote:
> robert <[EMAIL PROTECTED]> 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():
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
--
http://mail.python.org/mailman/listinfo/python-list
