Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, so we've got two points of dispute:

> 1) Jeff doesn't think the sigil should be part of the variable name

Which isn't practicable. We can't strip off the sigil for perl5. It's
part of the variable name, $foo and @foo are different items.

If you want to use a perl5 module from Python which has both $foo and
@foo exported, we can just pitch a fit. Everything else can be handled
by the import module.

And: we can't attach hints to the namespace lookup because you just
don't know, if Python wants the scalar "foo" or the array "foo". There
is exactly one "foo" object that Python can use, that's it.

Python allows only bare names in the import statement:

  from a import foo [ as a_foo ]

but not:

  from a import "@foo" [ as a_foo ]

> 2) Both Jeff and Jonathan have pointed out that languages we care
> about *do* have a combined function/varname store. (Though class
> names/namespaces seem to be separate)

No. Python just has names. Assigning something to a name binds that
thingy to that name. At bytecode level there is almost no indication
that you are working with classes except for the C<BUILD_CLASS> opcode
(not shown below).
E.g.:

class A(object):
    def foo(self):
        pass

a = A()
a.foo()
a = 7

The object instantiation is this:

  5          22 LOAD_NAME                1 (A)
             25 CALL_FUNCTION            0
             28 STORE_NAME               2 (a)

That's the "method" call:

  6          31 LOAD_NAME                2 (a)
             34 LOAD_ATTR                3 (foo)
             37 CALL_FUNCTION            0

And that's destroying the object by placing the object int("7")
into the name slot "a":

  7          41 LOAD_CONST               2 (7)
             44 STORE_NAME               2 (a)

The tricky part of Python "objects" is now to create real Parrot objects
out of it, which might be impossible for the general case. But for
normal cases the method call translates to a real Parrot method call,
with a method "foo" in namespace "A". Such methods would be usable from
Perl6 or other languages that use Parrot's object model.

Internally CPython passes the object to the method implicitely as Perl5
does - as the first argument of the function.

The only thing we can do is separate namespaces from names in it, so
that the namespace "A" doesn't collide with the class "A" from the
example above. But that's already Parrot internal, *if* the method
"foo" is translated to:

  .namespace ["A"]
  .sub foo method
  ...
  .end

Python per se doesn't have such a concept. It's more a matter of the HLL
compiler that translates Python or Perl5 then anything else.

leo

Reply via email to