[pypy-dev] Pypy bugs

[Elefterios Stamatogiannakis]

On 08/05/11 06:06, Dan Stromberg wrote:
>
> Hi Elefterios.
>
> I don't really work on PyPy, but I've written code that runs on PyPy and
> CPython 2&3 and Jython, unmodified.  I tried IronPython too, but it was
> too different from the others.

I don't really know how pypy wants to present itself. From reading the 
site and blog, i got the impression that pypy wishes to become an 
alternative to (and maybe replace it?) CPython, and not a "parallel 
universe" Python like Jython and IronPython. If this is indeed true, 
then pypy has to mirror some of the quirks and historic bugs of CPython, 
that people have come to depend on.

Nevertheless, i don't mind at all, if a porting effort is required to 
retarget something to also run on pypy. And from what i see, you have a 
lot more experience in doing this than me :-) .

>
> On Sat, May 7, 2011 at 6:13 PM, Elefterios Stamatogiannakis
> <estama at gmail.com <mailto:estama at gmail.com>> wrote:
>
>     Hi all, and many many thanks for pypy. Your work on pypy is exceptional.
>
>     Due to Roger Binns doing the first steps of porting APSW on top of pypy,
>     i've tried my project (madIS: http://code.google.com/p/madis ) with pypy
>     and head APSW, and found the following:
>
>     In python 2.7.1:
>     In [1]: print dict.__setattr__
>     <slot wrapper '__setattr__' of 'object' objects>
>
>     In pypy 1.5:
>     In [10]: print dict.__setattr__
>     <unbound method dict.__setattr__>
>
>     In essence in python 2.7.1 dict.__setattr__ is the same as
>     object.__setattr__ whereas in pypy dict.__setattr__ works only with
>     dictionaries, so it throws the following error when called with an
>     object:
>
>     TypeError: unbound method __setattr__() must be called with dict
>     instance as first argument
>
>     Above problem was solved by changing all dict.__setattr__ invocations
>     into object.__setattr__ invocations, and now the same code works in both
>     CPython and pypy.
>
>
> Actually, this feels a bit like it was a portability issue in your code
> to me.  Why should dict's __setattr__ apply to all objects?  Doesn't it
> seem more natural that it would apply to dicts alone, and if it applies
> to more, that that's an implementation detail?

You are right, and at first i too thought that CPython's behavior wasn't 
right. Nevertheless, maybe there is a reason that CPython behaves in 
this non consistent way, and other programs may hit this too.

As it is right now, i prefer pypy's implementation on this, as it makes 
more sense, and it is easily corrected.

>
>     The second problem that i found with pypy is this:
>
>     In [12]: import xml.etree.c
>     xml.etree.cElementTree
>
>     Above is to show that cElementTree exists in pypy's xml.etree. If then i
>     try to import cElementTree:
>
>     In [11]: import xml.etree.cElementTree
>     ---------------------------------------------------------------------------
>     ImportError                               Traceback (most recent
>     call last)
>
>     /home/estama/programs/pypy-15/bin/<ipython console> in <module>()
>
>     /home/estama/programs/pypy-15/lib-python/2.7/xml/etree/cElementTree.pyc
>     in <module>()
>            1 # Wrapper module for _elementtree
>
>            2
>     ----> 3 from _elementtree import *
>
>     ImportError: No module named _elementtree
>
>     Thanks again for pypy, and to Roger Binns for your outstanding work
>     on APSW.
>
>
> PyPy in general doesn't include a bunch of C extension modules; it's
> written in Python and RPython, so this seems somewhat natural.  Your
> code probably should do something like:
>
> try:
>     import xml.etree.cElementTree as element_tree
> except ImportError:
>     import xml.etree.ElementTree as element_tree
>
> ...and then use element_tree.whatever in your code.  It's 3 more lines,
> but more  portable.
>
> HTH.

You are exactly right, and i've more or less used code like the one you 
presented. My only problem is that i believe that pypy shouldn't have 
answered at my first example (In [12]:...) above that cElementTree 
exists in xml.etree .Or maybe it should short circuit cElementTree to 
point at ElementTree. To declare that something exists, and then when 
somebody tries to use it, to throw an exception, isn't that nice.

l.