tag:blogger.com,1999:blog-3971202189709462152.post3234492105090025733..comments2024-03-11T12:50:02.036+01:00Comments on PyPy Status Blog: Running Pylons on top of PyPyCarl Friedrich Bolz-Tereickhttp://www.blogger.com/profile/00518922641059511014noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-3971202189709462152.post-9589824297609197222008-06-12T18:40:00.000+02:002008-06-12T18:40:00.000+02:00I didn't "generates this", but "generalizes this"....I didn't "generates this", but "generalizes this". I think PJE's PEAK library also has stuff for this ("class advisors").Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-62152814445489559002008-06-12T18:34:00.000+02:002008-06-12T18:34:00.000+02:00Zope does things like:frame = sys.getframe(1)frame...Zope does things like:<BR/><BR/>frame = sys.getframe(1)<BR/>frame.f_locals['foo'] = bar<BR/><BR/>It does this to make zope.interface.implements() work, among other things. This allows you to the following:<BR/><BR/># IFoo is actually an instance, not a <BR/># class<BR/>class IFoo(zope.interface.Interface):<BR/> pass<BR/><BR/>class Myclass:<BR/> # stuffs information in the class<BR/> zope.interface.implements(IFoo)<BR/><BR/>The <A HREF="http://pypy.python.org/pypy/martian" REL="nofollow">martian library</A> (which Grok uses) actually generates this into its directive construct.<BR/><BR/>Some of this stuff could become class decorators in the future, I imagine, but we're stuck supporting this future for the forseeable future as well.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-8825837176969717622008-06-12T12:39:00.000+02:002008-06-12T12:39:00.000+02:00Well, if you plan on supporting, say, Zope or Twis...Well, if you plan on supporting, say, Zope or Twisted, you'll need to support modifying class-body frame locals.<BR/><BR/>There really isn't any point to optimizing them, not only due to PEP 3115, but also due to pre-3115 metaclasses. (And just the fact that most programs don't execute a lot of class suites in tight loops...)PJEhttps://www.blogger.com/profile/04688223805457202941noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-14728100843428091822008-06-12T10:57:00.000+02:002008-06-12T10:57:00.000+02:00PJE: What you say is mostly beside the point. PyPy...PJE: What you say is mostly beside the point. PyPy has no problem at all with non-string keys in (old-style) class dicts. The point is more that locals() cannot be used to assign things to this dictionary, see <A HREF="http://docs.python.org/lib/built-in-funcs.html" REL="nofollow">the docs</A>:<BR/><BR/>"<B>locals()</B><BR/> Update and return a dictionary representing the current local symbol table. Warning: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter."Carl Friedrich Bolz-Tereickhttps://www.blogger.com/profile/00518922641059511014noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-28619840647780708402008-06-12T02:10:00.000+02:002008-06-12T02:10:00.000+02:00It tests that SQLAlchemy isn't depending on class ...It tests that SQLAlchemy isn't depending on class dictionaries containing only string keys.<BR/><BR/>Unfortunately, this makes the test then depend on the ability to have non-string keys in the class dictionary. ;-)<BR/><BR/>The test is to ensure that SQLAlchemy will be able to map objects whose *classes* have AddOns defined.<BR/><BR/>By the way, as of PEP 3115, the locals() of a class can be an arbitrary object, so making compile-time assumptions about what *can't* be done with a class' locals() is probably not a good idea.<BR/><BR/>Also, as of every existing version of Python>=2.2, a metaclass may add non-dictionary keys to the class dictionary during class.__new__. So, it has never been a valid assumption that class __dict__ keys *must* be strings. If PyPy is relying on that, it is already broken, IMO.PJEhttps://www.blogger.com/profile/04688223805457202941noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-79804021785228841562008-06-11T22:50:00.000+02:002008-06-11T22:50:00.000+02:00Let's see who entered that line: 4361 pje ...Let's see who entered that line:<BR/><BR/> 4361 pje # This proves SA can handle a class with non-string dict keys<BR/> 4361 pje locals()[42] = 99 # Don't remove this line!<BR/><BR/><BR/>pje ? Yes. <A HREF="http://dirtsimple.org/" REL="nofollow">That PJE</A>. Complete with "don't remove this!"....we'll have to see what mr. guru was up to with that one. This test is also only present in the 0.5 branch which hasn't had alpha releases yet.<BR/><BR/>Would love to hear some other examples of "obscure details" the test suite is relying upon...my guess would be extremely few or none besides this one example.mike bayerhttps://www.blogger.com/profile/01417862951114999907noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-20342116550859231362008-06-11T14:38:00.000+02:002008-06-11T14:38:00.000+02:00Georgy Berdyshev is lurking in the #pypy channelg ...Georgy Berdyshev is lurking in the #pypy channelg (gberdyshev or similar), FWIW.Carl Friedrich Bolz-Tereickhttps://www.blogger.com/profile/00518922641059511014noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-35762199167617457122008-06-11T13:48:00.000+02:002008-06-11T13:48:00.000+02:00I see that the hyperlink to Georgy's report just n...I see that the hyperlink to Georgy's report just now got eaten by the comment software. <A HREF="http://sourceforge.net/mailarchive/forum.php?thread_name=ee8eb53d0806082009g5aec43dbn3da1f35b751cba70%40mail.gmail.com&forum_name=jython-dev" REL="nofollow">Here</A> it is again, hopefully working this time.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-88629778983037167002008-06-11T13:38:00.000+02:002008-06-11T13:38:00.000+02:00The Jython project is a summer of code project. Ge...The Jython project is a summer of code project. Georgy Berdyshev is the student and is sending messages to jython-dev.<BR/><BR/>Here was a recent status report:<BR/><BR/>http://sourceforge.net/mailarchive/forum.php?thread_name=ee8eb53d0806082009g5aec43dbn3da1f35b751cba70%40mail.gmail.com&forum_name=jython-devAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-36054975510124799132008-06-11T13:31:00.000+02:002008-06-11T13:31:00.000+02:00Hi Martijn, in fact having zope3 work with pypy wo...Hi Martijn, <BR/><BR/>in fact having zope3 work with pypy would be very nice. i discussed a bit with Phillip and he suggested to first get zope.interface and zope.component to work, then zope.proxy/zope.security. IIRC my first try with zope.interface yielded 3 failures out of 231 tests. I had to hack the test runner a bit to not rely on GC details - i guess that your work for Jython might imply that as well. What is the best way to follow your Jython work, btw?<BR/><BR/>best & cheers, <BR/>holgerholger krekelhttps://www.blogger.com/profile/00985924698593515074noreply@blogger.comtag:blogger.com,1999:blog-3971202189709462152.post-31848815345933458092008-06-11T01:46:00.000+02:002008-06-11T01:46:00.000+02:00Very good to see this work! This is a a good thing...Very good to see this work! This is a a good thing to be trying and hearing it makes me happy.<BR/><BR/>We're busy working on making Zope 3 run on Jython, which should get make some of our C level dependencies optional. These make a port to PyPy harder as well. Zope 3 libraries have umpteen thousands of tests that can be run, so that should give one some coverage. The libraries come packaged separately too. <BR/><BR/>The trickiest part would be those bits that depend on the ZODB. Porting the ZODB to PyPy should allow new possibilities, but it'll be hard too, I imagine.Anonymousnoreply@blogger.com