Mailman 3 January 2005 - pypy-dev

bug in http://codespeak.net/moin/pypy/moin.cgi/FrontPage?action=show
by Laura Creighton 10 Oct '05

10 Oct '05

If you click on the 'documentation' link you get a traceback! ooops. I will look at this later unless somebody beats me to it. Laura

5 4

Regular Expression in PyPy
by Seo Sanghyeon 31 Jan '05

31 Jan '05

In the checkin message of r8719, hpk wrote: > Ok, it seems we had a mix of python 2.4 and 2.3 moduels with > slight changes and were borrowing _sre from CPython anyway. > So let's back out our changes in pypy/lib and see how far we > get (if nobody minds, Seo?) But I mind! Let me explain this... Just before the checkin (r8718), there were following files in pypy/lib related to regular expression: re.py, dumbre.py, plexre.py, sre_adapt.py, sre_parse.py. You deleted re.py, sre_adapt.py, sre_parse.py. re.py contained (intended to contain) backend-neutral interface and utilities, like this: def match(pattern, string, flags=0): return compile(pattern, flags).match(string) And compile() does memoizing, just as CPython, etc. And re.escape() copied from CPython. These are backend-neutral. re.py imported Pattern class from the backend. Pattern's initializer has signature __init__(self, pattern, flags), and has methods of C type _sre.SRE_Pattern, like match, search, etc. And there were three backends (draft of backends) providing this Pattern class: dumbre.py, plexre.py, sre_adapt.py. Only sre_adapt.py imports CPython's _sre, others don't! You can read dumbre.py and plexre.py now, since you didn't delete them by mistake. :-) See, "dumbre.py" is exactly what you're referring as "see how far we get". It exits as soon as regular expression is used, and reports what was used. And this was the default re.py imported. (see below) "plexre.py" is more interesting, and it uses Plex to implement (for now) match(), but returns bool rather than full Match object. This is sufficient for all "if re.match(pattern, string):" tests, and this let pickle import and run, unmodified. (As I wrote in the log of r8636...) pickle uses regular expression only once, as following: __all__.extend([x for x in dir() if re.match("[A-Z][A-Z0-9_]+$",x)]) This also means PyPy interprets all of Plex just fine. Since Plex does regular expression parsing, NFA->DFA transformation, state machine all in pure Python, this is actually quite cool. "sre_adapt.py" is, as you see, cheating. It contains a single line: Pattern = sre_compile.compile And this does not work. Currently C types are not succesfully faked, so _sre.SRE_Pattern instances are created (well, see below) but all method calls will result in long traceback. I asked why is this on IRC long time ago, and I heard that it's because this C type lacks __dict__. Same applies for _random.Random, I think. That's why we have pure Python random.py from 2.2.3 in lib directory now. And why is sre_parse.py patched? Because, without those, no _sre.SRE_Pattern instances will be created, because PyPy fails to interpret some part of sre_parse.py. How to reproduce this problem: (with current PyPy) >>>> re.compile('a*') Traceback (application level): (snip) AttributeError: getwidth Why is this? I wrote my reasoning on the log of this file... r3332 and r3456. To show what's going on, I will give an example: class A: def getwidth(self): print 'hahaha' class B: def getwidth(self): print 'lalala' class C: def __getitem__(self, index): return A() def __getslice__(self, start, stop): return B() c = C() c[0].getwidth() c[0:1].getwidth() CPython prints hahaha and lalala. PyPy prints both hahaha. And sre_parse uses __getslice__... And this is the only place getslice is used, in entire Python standard library! (except those in UserList and UserString) And getslice is deprecated since release 2.0, as officially announced in Language Reference 3.3.6. Okay, can I back your deletion now? :-) Seo Sanghyeon

2 1

Regular Expression in PyPy
by Seo Sanghyeon 31 Jan '05

31 Jan '05

In the checkin message of r8719, hpk wrote: > Ok, it seems we had a mix of python 2.4 and 2.3 moduels with > slight changes and were borrowing _sre from CPython anyway. > So let's back out our changes in pypy/lib and see how far we > get (if nobody minds, Seo?) But I mind! Let me explain this... Just before the checkin (r8718), there were following files in pypy/lib related to regular expression: re.py, dumbre.py, plexre.py, sre_adapt.py, sre_parse.py. You deleted re.py, sre_adapt.py, sre_parse.py. re.py contained (intended to contain) backend-neutral interface and utilities, like this: def match(pattern, string, flags=0): return compile(pattern, flags).match(string) And compile() does memoizing, just as CPython, etc. And re.escape() copied from CPython. These are backend-neutral. re.py imported Pattern class from the backend. Pattern's initializer has signature __init__(self, pattern, flags), and has methods of C type _sre.SRE_Pattern, like match, search, etc. And there were three backends (draft of backends) providing this Pattern class: dumbre.py, plexre.py, sre_adapt.py. Only sre_adapt.py imports CPython's _sre, others don't! You can read dumbre.py and plexre.py now, since you didn't delete them by mistake. :-) See, "dumbre.py" is exactly what you're referring as "see how far we get". It exits as soon as regular expression is used, and reports what was used. And this was the default re.py imported. (see below) "plexre.py" is more interesting, and it uses Plex to implement (for now) match(), but returns bool rather than full Match object. This is sufficient for all "if re.match(pattern, string):" tests, and this let pickle import and run, unmodified. (As I wrote in the log of r8636...) pickle uses regular expression only once, as following: __all__.extend([x for x in dir() if re.match("[A-Z][A-Z0-9_]+$",x)]) This also means PyPy interprets all of Plex just fine. Since Plex does regular expression parsing, NFA->DFA transformation, state machine all in pure Python, this is actually quite cool. "sre_adapt.py" is, as you see, cheating. It contains a single line: Pattern = sre_compile.compile And this does not work. Currently C types are not succesfully faked, so _sre.SRE_Pattern instances are created (well, see below) but all method calls will result in long traceback. I asked why is this on IRC long time ago, and I heard that it's because this C type lacks __dict__. Same applies for _random.Random, I think. That's why we have pure Python random.py from 2.2.3 in lib directory now. And why is sre_parse.py patched? Because, without those, no _sre.SRE_Pattern instances will be created, because PyPy fails to interpret some part of sre_parse.py. How to reproduce this problem: (with current PyPy) >>>> re.compile('a*') Traceback (application level): (snip) AttributeError: getwidth Why is this? I wrote my reasoning on the log of this file... r3332 and r3456. To show what's going on, I will give an example: class A: def getwidth(self): print 'hahaha' class B: def getwidth(self): print 'lalala' class C: def __getitem__(self, index): return A() def __getslice__(self, start, stop): return B() c = C() c[0].getwidth() c[0:1].getwidth() CPython prints hahaha and lalala. PyPy prints both hahaha. And sre_parse uses __getslice__... And this is the only place getslice is used, in entire Python standard library! (except those in UserList and UserString) And getslice is deprecated since release 2.0, as officially announced in Language Reference 3.3.6. Okay, can I back your deletion now? :-) Seo Sanghyeon

1 0

Re: [pypy-svn] r8642 - pypy/dist/pypy/objspace/std
by Christian Tismer 28 Jan '05

28 Jan '05

ludal(a)codespeak.net wrote: > Author: ludal > Date: Thu Jan 27 18:06:26 2005 > New Revision: 8642 > > Modified: > pypy/dist/pypy/objspace/std/stringobject.py > Log: > keep a cache of the hash value of strings like CPython does Hi! I think it is a fine idea to do the hash cache. Just a comment...: > Modified: pypy/dist/pypy/objspace/std/stringobject.py ... > def hash__String(space, w_str): > - return W_IntObject(space, hash(w_str._value)) > + w_hash = w_str.w_hash > + if w_hash is None: > + w_hash = W_IntObject(space, hash(w_str._value)) > + w_str.w_hash = w_hash > + return w_hash I don't see the point why the hash should be stored as a wrapped value. IMHO, the main use of the hash is inside of dict objects. Wouldn't it make more sense to cache the unwrapped value, since we (as I think) do the hashing in a dict with an unwrapped integer, anyway? It is also more conformant with CPython, where the hash is an internal implementation detail. Maybe I just missed something, so anyway - good night! (Ludovic, I don't have your email contact) cheers - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

2 1

codespeak.net/pypy problem
by Jacek Generowicz 26 Jan '05

26 Jan '05

There seems to be a problem with the PyPy pages. This is what I get when I try to access any of them: A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /www/codespeak.net/htdocs/pypy/index.cgi 7 basedir = os.path.dirname(os.path.dirname(real)) 8 sys.path.insert(0, basedir) 9 10 from pypywww import cgi 11 cgi.main(basedir) pypywww undefined, cgi undefined SyntaxError: invalid syntax (cgi.py, line 29) args = ('invalid syntax', ('/projects/pypy/www/pypywww/cgi.py', 29, 9, ' <doc>: \n')) filename = '/projects/pypy/www/pypywww/cgi.py' lineno = 29 msg = 'invalid syntax' offset = 9 print_file_and_line = None text = ' <doc>: \n'

2 2

Re: [pypy-dev] module writing
by Florian Bauer 25 Jan '05

25 Jan '05

Hey Doug, I don't know exactly. Isn't there a pure python implementation for quoted printable in the python sources (I think in quopri.py or something). I would just use this code. Another thing: I don't have much time at the moment to finish my binascii code. Perhaps it's best if I pass my code to you, so you can have a look at it and perhaps merge it with yours and check it in? What do you think? Cheers Flo

2 1

[patch] fix for dot bad string generation
by Olivier Dormond 25 Jan '05

25 Jan '05

Here is a patch to fix dot producing label surounded by <> instead of ""

3 4

VEE conference
by Armin Rigo 24 Jan '05

24 Jan '05

Hi, A quick note: we should consider if we should propose a talk on PyPy at the new "Future of Virtual Execution Environmnents" conference, a conference-style follow-up of a closed workshop held last September in New York where I met a lot of interesting people. The focus is on anything about virtual machines. The first more specific area listed on the Call for Papers is "Dynamic and high-level languages". http://www.veeconference.org Armin

1 0

Re: [pypy-svn] r8426 - in pypy/branch/src-typedunwrap/pypy: interpreter/test objspace
by hpk＠trillke.net 21 Jan '05

21 Jan '05

Hi Samuele, i think in the tests you checked in there are "assert"s missing ... for example, On Wed, Jan 19, 2005 at 20:34 +0100, pedronis(a)codespeak.net wrote: > Author: pedronis > Date: Wed Jan 19 20:34:37 2005 > New Revision: 8426 > > Modified: > pypy/branch/src-typedunwrap/pypy/interpreter/test/test_gateway.py > pypy/branch/src-typedunwrap/pypy/objspace/trivial.py > + def g3(space, w_a, w_b): > + return space.add(w_a, w_b) > + app_g3 = gateway.interp2app_temp(g3, > + unwrap_spec=[gateway.ObjSpace, > + gateway.W_Root, > + gateway.W_Root]) > + w_app_g3 = space.wrap(app_g3) > + self.space.eq_w( > + space.call(w_app_g3, > + space.newtuple([w('foo'), w('bar')]), > + space.newdict([])), > + w('foobar')) this does not test equality (but it at least checks that it doesn't raise an unexpected exception :-) cheers, holger

1 0

[pycon@python.org: [Python-Dev] PyCon Preliminary Program Announced!]
by Armin Rigo 21 Jan '05

21 Jan '05

Hi all, PyCon is ready for registration, and the early bird rates end in one week. We've got a PyPy talk, "PyPy and Type Inference". Armin ----- Forwarded message from Steve Holden <pycon(a)python.org> ----- Date: Fri, 21 Jan 2005 01:06:05 +0100 (CET) From: Steve Holden <pycon(a)python.org> To: python-dev(a)python.org Subject: [Python-Dev] PyCon Preliminary Program Announced! Message-Id: <20050121000605.AAC3C1E400F(a)bag.python.org> Reply-To: PyCON(a)python.org List-Id: Python core developers <python-dev.python.org> List-Unsubscribe: <http://mail.python.org/mailman/listinfo/python-dev>, <mailto:python-dev-request@python.org?subject=unsubscribe> List-Archive: <http://mail.python.org/pipermail/python-dev> List-Post: <mailto:python-dev@python.org> List-Help: <mailto:python-dev-request@python.org?subject=help> List-Subscribe: <http://mail.python.org/mailman/listinfo/python-dev>, <mailto:python-dev-request@python.org?subject=subscribe> Sender: python-dev-bounces+arigo=tunes.org(a)python.org Errors-To: python-dev-bounces+arigo=tunes.org(a)python.org Dear Python Colleague: You will be happy to know that the PyCon Program Committee, after lengthy deliberations, has now finalized the program for PyCon DC 2005. I can tell you that the decision-making was very difficult, as the standard of submissions was even higher than last year. You can see the preliminary program at http://www.python.org/pycon/2005/schedule.html and it's obvious that this year's PyCon is going to be even fuller than the last. On innovation is that there will be activities of a more social nature on the Wednesday (and perhaps the Thursday) evening, as well as keynote speeches from Guido and two other luminaries. Remember that the early bird registration rates end in just over a week, so hurry on down to http://www.python.org/pycon/2005/register.html to be sure of your place in what will surely be the premier Python event of the year. As always, I would appreciate your help in getting the word out. Please forward this message to your favorite mailing lists and newsgroups to make sure that everyone has a chance to join in the fun! regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/arigo%40tunes.org ----- End forwarded message -----

1 0