Hi All,
Decided to test the 1.4 with a couple of my usecases, got quite
surprising results...
To keep it short, I have several usecases that involve replacing the
object dictionary.
Here's a simple example:
---cut---
class D(dict):
def __setitem__(self, key, value):
print 'updating attr "%s" to "%s"...' % (key, value)
super(D, self).__setitem__(key, value)
class X(object): pass
x = X()
x.__dict__ = D()
x.a = 1 # will print a nice log string...
# NOTE: this will not print anything …
[View More]in CPython (see P.S.)
--uncut--
With the release of version 1.4, I decided to test these usecases out
and benchmark them on PyPy and 15 minutes later I got results that
were surprising to say the least...
Expectations:
1) the normal/native namespace should have been a bit faster than the
hooked object on the first run. Both cases should have leveled to
about the same performance after the JIT finished it's job +/- a
constant.
2) all times should have been near constant.
What I got per point:
1) the object with native dict was slower by about three orders of
magnitude than the object with a hooked namespace.
2) sequential write benchmark runs on the normal object did not level
out, as they did with the hook, rather, they exhibited exponential
times (!!)
For details and actual test code see the attached file.
P.S. This specific functionality is a weak point in CPython for two reasons:
1) writing to .__dict__ demands a subclass of dict (not a real
problem, though over-restrictive in my view)
2) all interactions with the namespace are done directly via the
Python C-API, completely neglecting the high-level dict interface.
Thanks!
--
Alex.
[View Less]
Hi,
what xml libraries are people using with pypy? What is working well?
cu,
On Sun, Nov 28, 2010 at 9:48 AM, Maciej Fijalkowski <fijall(a)gmail.com>wrote:
> Hey.
>
> On Sun, Nov 28, 2010 at 10:57 AM, Phyo Arkar <phyo.arkarlwin(a)gmail.com>
> wrote:
> > i got python-magic working , after i installed without easy_install
> > (easy_install fail because it tried to install ctypes).
>
> great
>
> >
> > Now what is not working is python-…
[View More]lxml , which is very important for my
> project.
>
> lxml won't work out of the box. if you think it's important enough,
> you can try to port cython to generate something saner (right now what
> it generates won't work on cpyext).
>
> Cheers,
> fijal
>
> >
> > here are the errors:
> >
> > Running lxml-2.3beta1/setup.py -q bdist_egg --dist-dir
> > /tmp/easy_install-Gg3GRA/lxml-2.3beta1/egg-dist-tmp-bwUkM2
> > Building lxml version 2.3.beta1.
> > NOTE: Trying to build without Cython, pre-generated
> > 'src/lxml/lxml.etree.c' needs to be available.
> > Using build configuration of libxslt 1.1.26
> > Building against libxml2/libxslt in the following directory: /usr/lib
> > src/lxml/lxml.etree.c:75: error: conflicting types for ‘Py_buffer’
> > /home/v3ss/pypy-1.4/include/object.h:19: note: previous declaration of
> > ‘Py_buffer’ was here
> >
> >
> > Had Anyone got lxml working in pypy successfully?
> >
> > On 11/27/10, Antonio Cuni <anto.cuni(a)gmail.com> wrote:
> >> On 27/11/10 03:09, Phyo Arkar wrote:
> >>> libmagic python fails to work on pypy (python-magic)
> >>>
> >>> it uses ctypes and easy-install try to download and instaill it , but
> it
> >>> fails.
> >>>
> >>> how to enable ctypes on pypy?
> >>
> >> Hi Phyo,
> >> ctypes *is* enabled on pypy by default.
> >>
> >> If python-magic does not work, it can either:
> >>
> >> 1) be a pypy bug: please report it as an issue (possibly with a simple
> >> failing
> >> test and the full traceack)
> >>
> >> 2) a python-magic issue, e.g. if it plays dirty ctypes trick that cannot
> >> really be supported by pypy due to the internal differences with CPython
> >>
> >> ciao,
> >> Anto
> >>
> > _______________________________________________
> > pypy-dev(a)codespeak.net
> > http://codespeak.net/mailman/listinfo/pypy-dev
> >
> _______________________________________________
> pypy-dev(a)codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>
[View Less]
