On Sep 29, 2004, at 9:01 PM, Brent 'Dax' Royal-Gordon wrote:
[Argh...]
Chip Salzenberg <[EMAIL PROTECTED]> wrote:parrot_alias(a, 'b', # dest: Python is unified, no need for a category here
a, 'b', 'scalar') # src: Perl is not unified, so source category is required
parrot_alias(a, 'c',
a, 'c', 'array') # here's a different category, to get '@c'
or some such. Yes it's ugly. But if we can't fix a ditch, the least we can do is put a big friendly warning sign on it.
Turns out the ugliness isn't needed anyway; Python already has a syntax to access a namespace entry by string name (via __dict__), and Python import copy anyway, rather than alias. That is, this:
from os import WNOHANG
creates a "WNOHANG" variable in the local namespace with the value of "os. WNOHANG", but it's a copy--changing one changes the other. So, one could do this:
foo = Perl.Blah.__dict__["some-japanese-variable-name"]
when the variable name isn't something Python can accommodate directly, and get the same result.
Another way to do it would be to have each "category" actually be a namespace. In other words, Perl's namespaces are structured like this:
File => package { ns => package { Find => package { sub => package { find => { ... } } }, Path => package { sub => package { BUILD => { ... }, DESTROY => { ... } } } ... }, scalar => package { some_idiot => "put a variable in this package" } }
And Python would access them like so: File.ns.Path.sub.new()
Not perfect, certainly, but it would work, and be reasonably elegant.
Yep, this is exactly what I had in mind. Everything is hash-like anyway, so whether you call the category a namespace or just something namespace-like (since it's hash-like), doesn't matter so much, and on the Python side they're all just things which allow named attribute lookup.
(This does pose a problem going the other way, but I suspect Perl could simply mark its own packages in some way, and fall back to a simpler scheme, such as "ignore the sigil", when it's munging another language's namespaces.)
I'd think that, when importing a module, you'd need a concept of what structure of namespace you're dealing with (which maps roughly to what language was used to implement the module, though "flat namespace" languages might all act the same). As I touched on in another post, I think you'd need to concept of a wrapper--for instance, when Python code pulls in a Perl module, it would get a wrapper which acts Pythonish, and acts as a go-between for the real namespace. (Probably, this would be via namespace tie-ing.)
In this light, I think that going the other way is easy--all Python variables would look to Perl like scalars holding references (since this is the semantics that Python variables have). But see my recent post in the "Namespaces, part 1 (new bits)" thread for some caveats.
JEff
