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 > <est...@gmail.com <mailto:est...@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. _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
