[Zope-Perl] Mixing perl arrays with python lists

[Jim Fulton]

Gisle Aas wrote:
> 
> I have a python extension type that wraps a perl array.  The extension
> type make sure that such wrapped up perl arrays can be operated (from
> python) the same way as python lists, i.e. allow item subscription,
> taking slices, assigning to slices as well as implementing the list
> methods (append, pop, index, reverse,...)
> 
> If python calls a perl function that returns an array reference, then
> such a wrap up will be the result.  You might also get it by taking
> explicit references to stuff inside the perl name space,
> e.g. perl.get_ref("@INC").
> 
> The question is: Should perl arrays allow python lists (and tuples) to
> be used as arguments to its functions or should we require the other
> argument(s) to always be another perl array thingy.
> 
>    array = perl.get_ref("@")    # gives you a new empty array
>    array[:] = [1,2,3];          # should this be allowed

Yes, at least in the long run. Furthermore, if possible, it should
be possible to pass a Python list to a perl function that accepts
an array. Does perl have any abstract notion of arrayness that 
admits multiple array implementations?

> The python way seems to be to never allow mixing types and to provide
> the functions list() and tuple() to do explicit conversions where you
> want them to be allowed. 

I don't agree that this is the Python way. At one time, it was easier
to write Python extensions that required a specific type, however,
the Python abstract-object C API fixed that several years ago.
Occasionally, a Python facility may require a specific type as
an optimization, which I consider a valid compromise, but it is 
otherwise better to allow a range of types (e.g. "sequences") 
whenever possible.

> I could do something similar and provide a
> perl.array() that turns any sequence object into a new perl array.
> That would make the example above:
> 
>    array[:] = perl.array([1,2,3])
> 
> The same thing also applies for the relationship between perl hashes
> and python dicts.  Should hash.update({...}) be allowed?

Yes, in the long term. If in the short term, it is necessary or expedient 
to use explicit conversions, then that's OK, IMO.

In the long term, it would be nicer to be able to intermix types.
For example, it would be nice to be able to pass a list or
dictionary, or some other mutable collection types to perl functions
that mutate collections and get the Python objects mutated.
 
> As the perl person I am, I tend to want to allow any argument that
> makes sense.  Is this the wrong thing to do? 

No.

> After all, this is the
> API that python programmers see, and they seem to want exceptions to
> occur at every possible opportunity :-)

Python is significantly about OO, which encompases polymorphism.
Python programmers expect to be able to use multiple object implementations,
which implement the same interfaces, interchangeably. Where Python programmers
get a tad fussier is mixing apples and oranges, like numbers and strings.
Of course, fruit classification is in the eye of the grocer, uh, or 
something. ;)

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.