From lac at strakt.com Fri Jun 4 16:24:07 2004 From: lac at strakt.com (Laura Creighton) Date: Fri, 04 Jun 2004 16:24:07 +0200 Subject: [pypy-dev] Re: [pypy-svn] r4909 - in pypy/branch/src-newobjectmodel/pypy: interpreter objspace objspace/std In-Reply-To: Message from arigo@codespeak.net of "Fri, 04 Jun 2004 16:16:46 +0200." <20040604141646.73D925BE07@thoth.codespeak.net> References: <20040604141646.73D925BE07@thoth.codespeak.net> Message-ID: <200406041424.i54EO7KH025257@ratthing-b246.strakt.com> Wow. The world is over indeed. At any rate, it looks like I might get to write soem code today after all. My idea is to take the builditn checker and make it spit out html. I know very little about generating html, but Ihave some nice books here. Of course, what would be best is if you already had a page that mostly did what you want this page to do, so I could simply 'make one like that'. Anybody got a candidate? Laura - reading html book while peeling potatoes From mwh at python.net Tue Jun 15 16:42:24 2004 From: mwh at python.net (Michael Hudson) Date: Tue, 15 Jun 2004 15:42:24 +0100 Subject: [pypy-dev] stuff Message-ID: <2mn034ann3.fsf@starship.python.net> A random rag-bag of thoughts: 1) I have a rather cleaner, though currently less complete application-level implementation of the string formatting goo. It's split amongst a couple of classes, quite a few functions and some global data. I'm not sure how this should be tied into the stdobjspace. It would probably be better if they lived in a separate module. We don't have a gateway.import_from_app_module hiding somewhere, or do we? 2) We could do with more 'applicationy' goals compared to the rather 'lanugagey' ones like running pypy or running utest. 3) could 'non-reimplementations' like longobject.py be auto generated? On the fly, even? It would seem a better solution than cpythonobject.py (I guess longobject is special because of the interaction with ints, but for e.g. files it shouldn't be too hard). Cheers, mwh -- "Sturgeon's Law (90% of everything is crap) applies to Usenet." "Nothing guarantees that the 10% isn't crap, too." -- Gene Spafford's Axiom #2 of Usenet, and a corollary From hpk at trillke.net Tue Jun 15 16:58:54 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 16:58:54 +0200 Subject: [pypy-dev] stuff In-Reply-To: <2mn034ann3.fsf@starship.python.net> References: <2mn034ann3.fsf@starship.python.net> Message-ID: <20040615145854.GJ19360@solar.trillke> [Michael Hudson Tue, Jun 15, 2004 at 03:42:24PM +0100] > A random rag-bag of thoughts: > > 1) I have a rather cleaner, though currently less complete > application-level implementation of the string formatting goo. > It's split amongst a couple of classes, quite a few functions and > some global data. I'm not sure how this should be tied into the > stdobjspace. It would probably be better if they lived in a > separate module. We don't have a gateway.import_from_app_module > hiding somewhere, or do we? We don't have that currently. How much "app-level" is your code, btw, considering that we usually can safely unwrap strings? I think you could put a _stringhelper.py into appspace and use that from the app-level definition of app_mod__String_ANY IIUC. We probably also will want to split up the app-level code of __builtin__ aka __builtin__module.py into multiple files i think. The recent addition of "complex" to the builtins highlighted this need. > 2) We could do with more 'applicationy' goals compared to the rather > 'lanugagey' ones like running pypy or running utest. yes, certainly true. > 3) could 'non-reimplementations' like longobject.py be auto generated? > On the fly, even? It would seem a better solution than > cpythonobject.py (I guess longobject is special because of the > interaction with ints, but for e.g. files it shouldn't be too > hard). seems like an interesting approach to me. I am not sure, though, how something like long-objects could be generated fully on the fly considering coercion rules. For files this is probably a non-issue. Note that these days, apart from Files and wholly-wrapped cpython-modules, we don't have all that many cpythonobject-wrapped thingies around, anymore. cheers, holger From mwh at python.net Tue Jun 15 17:38:56 2004 From: mwh at python.net (Michael Hudson) Date: Tue, 15 Jun 2004 16:38:56 +0100 Subject: [pypy-dev] Re: stuff References: <2mn034ann3.fsf@starship.python.net> <20040615145854.GJ19360@solar.trillke> Message-ID: <2misdsal0v.fsf@starship.python.net> holger krekel writes: > [Michael Hudson Tue, Jun 15, 2004 at 03:42:24PM +0100] >> A random rag-bag of thoughts: >> >> 1) I have a rather cleaner, though currently less complete >> application-level implementation of the string formatting goo. >> It's split amongst a couple of classes, quite a few functions and >> some global data. I'm not sure how this should be tied into the >> stdobjspace. It would probably be better if they lived in a >> separate module. We don't have a gateway.import_from_app_module >> hiding somewhere, or do we? > > We don't have that currently. How much "app-level" is your code, btw, > considering that we usually can safely unwrap strings? Enough that it would be painful to rewrite at interp level. > I think you could put a _stringhelper.py into appspace and use that > from the app-level definition of app_mod__String_ANY IIUC. Guess so, but I don't think we have the equivalent of PyImport_ImportModule() yet, do we? > We probably also will want to split up the app-level code of __builtin__ aka > __builtin__module.py into multiple files i think. The recent addition > of "complex" to the builtins highlighted this need. I believe you, but didn't get caught up in the discussion on that one. >> 2) We could do with more 'applicationy' goals compared to the rather >> 'lanugagey' ones like running pypy or running utest. > > yes, certainly true. > >> 3) could 'non-reimplementations' like longobject.py be auto generated? >> On the fly, even? It would seem a better solution than >> cpythonobject.py (I guess longobject is special because of the >> interaction with ints, but for e.g. files it shouldn't be too >> hard). > > seems like an interesting approach to me. I am not sure, though, > how something like long-objects could be generated fully on the fly > considering coercion rules. For files this is probably a non-issue. That's what I said :-) > Note that these days, apart from Files and wholly-wrapped cpython-modules, we > don't have all that many cpythonobject-wrapped thingies around, anymore. True. Cheers, mwh -- Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises. -- from the announcement of the beta of "Pinstripe" aka. Redhat 7.0 From hpk at trillke.net Tue Jun 15 18:00:29 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 18:00:29 +0200 Subject: [pypy-dev] Re: stuff In-Reply-To: <2misdsal0v.fsf@starship.python.net> References: <2mn034ann3.fsf@starship.python.net> <20040615145854.GJ19360@solar.trillke> <2misdsal0v.fsf@starship.python.net> Message-ID: <20040615160029.GL19360@solar.trillke> [Michael Hudson Tue, Jun 15, 2004 at 04:38:56PM +0100] > holger krekel writes: > > [Michael Hudson Tue, Jun 15, 2004 at 03:42:24PM +0100] > > I think you could put a _stringhelper.py into appspace and use that > > from the app-level definition of app_mod__String_ANY IIUC. > > Guess so, but I don't think we have the equivalent of > PyImport_ImportModule() yet, do we? no. But you need to have that app_mod__String_ANY thingie, anyway and can import from there, as far as i see. > >> 3) could 'non-reimplementations' like longobject.py be auto generated? > >> On the fly, even? It would seem a better solution than > >> cpythonobject.py (I guess longobject is special because of the > >> interaction with ints, but for e.g. files it shouldn't be too > >> hard). > > > > seems like an interesting approach to me. I am not sure, though, > > how something like long-objects could be generated fully on the fly > > considering coercion rules. For files this is probably a non-issue. > > That's what I said :-) ups, sorry. forgot about the parenthesis part :-) > > Note that these days, apart from Files and wholly-wrapped cpython-modules, we > > don't have all that many cpythonobject-wrapped thingies around, anymore. > > True. so maybe it's not worth the effort to seriously think about it if we are only talking abut Files? holger From mwh at python.net Tue Jun 15 18:06:31 2004 From: mwh at python.net (Michael Hudson) Date: Tue, 15 Jun 2004 17:06:31 +0100 Subject: [pypy-dev] Re: stuff References: <2mn034ann3.fsf@starship.python.net> <20040615145854.GJ19360@solar.trillke> <2misdsal0v.fsf@starship.python.net> <20040615160029.GL19360@solar.trillke> Message-ID: <2mekogajqw.fsf@starship.python.net> holger krekel writes: > [Michael Hudson Tue, Jun 15, 2004 at 04:38:56PM +0100] >> holger krekel writes: >> > [Michael Hudson Tue, Jun 15, 2004 at 03:42:24PM +0100] >> > I think you could put a _stringhelper.py into appspace and use that >> > from the app-level definition of app_mod__String_ANY IIUC. >> >> Guess so, but I don't think we have the equivalent of >> PyImport_ImportModule() yet, do we? > > no. But you need to have that app_mod__String_ANY thingie, anyway > and can import from there, as far as i see. Oh yeah :-) >> > Note that these days, apart from Files and wholly-wrapped cpython-modules, we >> > don't have all that many cpythonobject-wrapped thingies around, anymore. >> >> True. > > so maybe it's not worth the effort to seriously think about it if we > are only talking abut Files? Maybe not. But it might help for other extension types, too... Cheers, mwh -- If you don't use emacs, you're a pathetic, mewling, masochistic weakling and I can't be bothered to convert you. -- Ron Echeverri From arigo at tunes.org Tue Jun 15 18:56:07 2004 From: arigo at tunes.org (Armin Rigo) Date: Tue, 15 Jun 2004 17:56:07 +0100 Subject: [pypy-dev] utest conversion Message-ID: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> Hi, Building on a suggestion by Jacob on how to safely convert old-style unittests "self.assertEquals(x,y)" into new-style utest "assert x == y": the difficulty is not to find the self.assertEquals() in the test sources, but to safely identify the comma between the two arguments, and not mistake it with some other comma that could appear in x or in y. There was talk about subtle string parsing, or about using Python's parser or compiler package, but actually it is much easier than that... Just try to split the text "x,y" between the parenthesis in two halves at every possible comma position, until both halves compile without raising SyntaxError :-) Armin From hpk at trillke.net Tue Jun 15 19:06:45 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 19:06:45 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> Message-ID: <20040615170645.GN19360@solar.trillke> [Armin Rigo Tue, Jun 15, 2004 at 05:56:07PM +0100] > Hi, > > Building on a suggestion by Jacob on how to safely convert old-style unittests > "self.assertEquals(x,y)" into new-style utest "assert x == y": the difficulty > is not to find the self.assertEquals() in the test sources, but to safely > identify the comma between the two arguments, and not mistake it with some > other comma that could appear in x or in y. > > There was talk about subtle string parsing, or about using Python's parser or > compiler package, but actually it is much easier than that... Just try to > split the text "x,y" between the parenthesis in two halves at every possible > comma position, until both halves compile without raising SyntaxError :-) Yes, that reminds me of my favourite "try-parsing" technique (used in rlcompleter2 and elsewhere :-) Actually you also need to check for multiline-parseability first. IIRC we do have a quite a bit of multiline-asserts. cheers, holger From jacob at strakt.com Tue Jun 15 19:14:34 2004 From: jacob at strakt.com (Jacob =?iso-8859-1?q?Hall=E9n?=) Date: Tue, 15 Jun 2004 19:14:34 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: <20040615170645.GN19360@solar.trillke> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615170645.GN19360@solar.trillke> Message-ID: <200406151914.34125.jacob@strakt.com> On tisdag 15 juni 2004 19.06, holger krekel wrote: > [Armin Rigo Tue, Jun 15, 2004 at 05:56:07PM +0100] > > > Hi, > > > > Building on a suggestion by Jacob on how to safely convert old-style > > unittests "self.assertEquals(x,y)" into new-style utest "assert x == y": > > the difficulty is not to find the self.assertEquals() in the test > > sources, but to safely identify the comma between the two arguments, and > > not mistake it with some other comma that could appear in x or in y. > > > > There was talk about subtle string parsing, or about using Python's > > parser or compiler package, but actually it is much easier than that... > > Just try to split the text "x,y" between the parenthesis in two halves at > > every possible comma position, until both halves compile without raising > > SyntaxError :-) > > Yes, that reminds me of my favourite "try-parsing" technique (used > in rlcompleter2 and elsewhere :-) > > Actually you also need to check for multiline-parseability first. IIRC > we do have a quite a bit of multiline-asserts. Laura has solved the try-parsing problem, so it isn't just a suggestion any more. Jacob From lac at strakt.com Tue Jun 15 19:44:54 2004 From: lac at strakt.com (Laura Creighton) Date: Tue, 15 Jun 2004 19:44:54 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: Message from Jacob =?iso-8859-1?q?Hall=E9n?= of "Tue, 15 Jun 2004 19:14:34 +0200." <200406151914.34125.jacob@strakt.com> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615170645.GN19360@solar.trillke> <200406151914.34125.jacob@strakt.com> Message-ID: <200406151744.i5FHiset024114@ratthing-b246.strakt.com> In a message of Tue, 15 Jun 2004 19:14:34 +0200, Jacob Hall?n writes: >On tisdag 15 juni 2004 19.06, holger krekel wrote: >> [Armin Rigo Tue, Jun 15, 2004 at 05:56:07PM +0100] >> >> > Hi, >> > >> > Building on a suggestion by Jacob on how to safely convert old-style >> > unittests "self.assertEquals(x,y)" into new-style utest "assert x == >y": >> > the difficulty is not to find the self.assertEquals() in the test >> > sources, but to safely identify the comma between the two arguments, >and >> > not mistake it with some other comma that could appear in x or in y. >> > >> > There was talk about subtle string parsing, or about using Python's >> > parser or compiler package, but actually it is much easier than that. >.. >> > Just try to split the text "x,y" between the parenthesis in two halve >s at >> > every possible comma position, until both halves compile without rais >ing >> > SyntaxError :-) >> >> Yes, that reminds me of my favourite "try-parsing" technique (used >> in rlcompleter2 and elsewhere :-) >> >> Actually you also need to check for multiline-parseability first. IIRC >> we do have a quite a bit of multiline-asserts. > >Laura has solved the try-parsing problem, so it isn't just a suggestion a >ny >more. > >Jacob >_______________________________________________ >pypy-dev at codespeak.net >http://codespeak.net/mailman/listinfo/pypy-dev I got the stuff working with compile too!(i.e. don't race out there and implement this before I get my checkin). Right now the great problem is files that look like this: .......... .......... self.assertEquals(x, y) # check for unmatched () ......... where the last ')' in the comment is the one that gets split and multi-line comments that start self.assertEquals t.ex ''' Here is something which will confuse things a lot self.assertEquals(x, y) will be converted to assert x == y ''' Right now my program will mistake that for program text to be converted. I wonder if this is a real problem for us? Also, the compile needs to get a string with the leading indentation stripped right off, i.e. self.assertEquals(x + f(y, z) + (z + 1), 42) needs to make the strings x + f(y, z) + z + 1 and 42 so as not to get a syntax error on the unexpected indentation. I wonder if we have text where people mix spaces and tabs on the leading line on purpose? If so my program is going to despair and demand a human to fix it. I will get done making dinner, then check in what I have. It was rather fun ... Thank you Armin for the idea over dinner ... Laura From hpk at trillke.net Tue Jun 15 20:07:00 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 20:07:00 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: <200406151744.i5FHiset024114@ratthing-b246.strakt.com> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615170645.GN19360@solar.trillke> <200406151914.34125.jacob@strakt.com> <200406151744.i5FHiset024114@ratthing-b246.strakt.com> Message-ID: <20040615180700.GO19360@solar.trillke> [Laura Creighton Tue, Jun 15, 2004 at 07:44:54PM +0200] > I got the stuff working with compile too!(i.e. don't race out there and > implement this before I get my checkin). > > Right now the great problem is files that look like this: > > .......... > .......... > self.assertEquals(x, y) # check for unmatched () > ......... > > where the last ')' in the comment is the one that gets split > and multi-line comments that start self.assertEquals t.ex i think it makes sense to detect (and possibly preserve) comment-parts before-hand. > ''' > Here is something which will confuse things a lot > > self.assertEquals(x, y) will be converted to assert x == y > > ''' this exact thing should fail the (multiline-) parseability-test IIUC. > Also, the compile needs to get a string with the leading indentation > stripped right off, i.e. > > self.assertEquals(x + f(y, z) + > (z + 1), > 42) > > needs to make the strings > > x + f(y, z) + z + 1 > > and > > 42 > > so as not to get a syntax error on the unexpected indentation. We should be safe with trying-to-compile "(" + part + ")" which basically lets you ignore indentation. (We only have expressions so adding parenthesis should be safe). When actually writing out the assert-statement you can do something like " ".join(expr.split()) to forget about all indentation. As a bonus it would be nice to write out multiple lines if the linewidth gets greater 75 or so. Of course parentheses are required around the expression part of such a multiline assert-statement like assert (x + verylongfunctioncall(y, z) + longvariablename + 1 == some_expected_result) cheers and have a good dinner, holger From hpk at trillke.net Tue Jun 15 20:13:50 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 20:13:50 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> Message-ID: <20040615181350.GP19360@solar.trillke> [Armin Rigo Tue, Jun 15, 2004 at 05:56:07PM +0100] > There was talk about subtle string parsing, or about using Python's parser or > compiler package, but actually it is much easier than that... Just try to > split the text "x,y" between the parenthesis in two halves at every possible > comma position, until both halves compile without raising SyntaxError :-) btw, using import parser parser.expr(string) is way faster than invoking the whole compiling machinery. Of course, 'compile' doesn't require an import builtin but then again you have to think up arbitrary arguments to this builtin :-) holger From lac at strakt.com Tue Jun 15 20:52:22 2004 From: lac at strakt.com (Laura Creighton) Date: Tue, 15 Jun 2004 20:52:22 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: Message from holger krekel of "Tue, 15 Jun 2004 20:07:00 +0200." <20040615180700.GO19360@solar.trillke> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615170645.GN19360@solar.trillke> <200406151914.34125.jacob@strakt.com> <200406151744.i5FHiset024114@ratthing-b246.strakt.com> <20040615180700.GO19360@solar.trillke> Message-ID: <200406151852.i5FIqM32024461@ratthing-b246.strakt.com> In a message of Tue, 15 Jun 2004 20:07:00 +0200, holger krekel writes: >> Right now the great problem is files that look like this: >> >> .......... >> .......... >> self.assertEquals(x, y) # check for unmatched () >> ......... >> >> where the last ')' in the comment is the one that gets split >> and multi-line comments that start self.assertEquals t.ex > >i think it makes sense to detect (and possibly preserve) comment-parts be >fore-hand. I don't see how that helps my problem, which is that of stripping the unwanted trailing ). At any rate, before the latest refactor that self.assertEquals(x, y) # check for unmatched () would produce assert x == y) # check for unmatched ( which wasn't the idea ... :-) > >> ''' >> Here is something which will confuse things a lot >> >> self.assertEquals(x, y) will be converted to assert x == y >> >> ''' > >this exact thing should fail the (multiline-) parseability-test IIUC. What does IIUC mean again? > >> Also, the compile needs to get a string with the leading indentation >> stripped right off, i.e. >> >> self.assertEquals(x + f(y, z) + >> (z + 1), >> 42) >> >> needs to make the strings >> >> x + f(y, z) + z + 1 >> >> and >> >> 42 >> >> so as not to get a syntax error on the unexpected indentation. > >We should be safe with trying-to-compile "(" + part + ")" which basically >lets you ignore indentation. (We only have expressions so adding parenthesis >should be safe). I should have thought of that. Thank you. >When actually writing out the assert-statement you >can do something like > > " ".join(expr.split()) > >to forget about all indentation. I've been saving it, just as its author put it in. Since assert is shorter than self.assertEquals, this means that whatever indentation the assertEqual writer wanted, will get preserved. Of course, we will see if this continues after I handle multiline comments better. Laura From lac at strakt.com Tue Jun 15 21:23:40 2004 From: lac at strakt.com (Laura Creighton) Date: Tue, 15 Jun 2004 21:23:40 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: Message from holger krekel of "Tue, 15 Jun 2004 20:13:50 +0200." <20040615181350.GP19360@solar.trillke> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615181350.GP19360@solar.trillke> Message-ID: <200406151923.i5FJNeEt024559@ratthing-b246.strakt.com> Is it reasonable to simplyfy the solution so that people who write: self.assertEquals(True, self.assertEquals(0,0) ) get what they deserve, i.e. flogging with wet noodles until dawn? (I had forgotten how much fun breaking parsers is ...) Laura From hpk at trillke.net Tue Jun 15 21:32:45 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 21:32:45 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: <200406151923.i5FJNeEt024559@ratthing-b246.strakt.com> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615181350.GP19360@solar.trillke> <200406151923.i5FJNeEt024559@ratthing-b246.strakt.com> Message-ID: <20040615193245.GQ19360@solar.trillke> [Laura Creighton Tue, Jun 15, 2004 at 09:23:40PM +0200] > > Is it reasonable to simplyfy the solution so that people who write: > > self.assertEquals(True, > self.assertEquals(0,0) > ) > > get what they deserve, i.e. flogging with wet noodles until dawn? actually the above statement doesn't make much sense as the 'assert*' methods of unittest.py usually return None. So yes, recursive assert constructions should not overly worry you. Something else: It would be good if you switched to working on the trunk-version of PyPy. The branch/src-newobjectmodel is basically out of order and has been merged back into the trunk on the sunday before EuroPython 2004. (You can see where you are via "svn info" in e.g. the src/ directory). cheers, holger P.S.: IIUC means If i understand correctly. From lac at strakt.com Tue Jun 15 21:57:55 2004 From: lac at strakt.com (Laura Creighton) Date: Tue, 15 Jun 2004 21:57:55 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: Message from holger krekel of "Tue, 15 Jun 2004 21:32:45 +0200." <20040615193245.GQ19360@solar.trillke> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615181350.GP19360@solar.trillke> <200406151923.i5FJNeEt024559@ratthing-b246.strakt.com> <20040615193245.GQ19360@solar.trillke> Message-ID: <200406151957.i5FJvt79024621@ratthing-b246.strakt.com> In a message of Tue, 15 Jun 2004 21:32:45 +0200, holger krekel writes: >[Laura Creighton Tue, Jun 15, 2004 at 09:23:40PM +0200] >> >> Is it reasonable to simplyfy the solution so that people who write: >> >> self.assertEquals(True, >> self.assertEquals(0,0) >> ) >> >> get what they deserve, i.e. flogging with wet noodles until dawn? > >actually the above statement doesn't make much sense as >the 'assert*' methods of unittest.py usually return None. >So yes, recursive assert constructions should not overly worry you. > >Something else: It would be good if you switched to working on >the trunk-version of PyPy. The branch/src-newobjectmodel is basically >out of order and has been merged back into the trunk on the sunday >before EuroPython 2004. (You can see where you are via "svn info" >in e.g. the src/ directory). I'm not there. I'm in http://codespeak.net/svn/pypy/branch/src-new-utest/pypy/tool and I made that branch the thursday or Friday after EP. Do you want me to move? Laura, who figures she should go mangle a copy of the trunk first, at any rate ... > >cheers, > > holger > >P.S.: IIUC means If i understand correctly. From hpk at trillke.net Tue Jun 15 22:05:09 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 22:05:09 +0200 Subject: [pypy-dev] utest conversion In-Reply-To: <200406151957.i5FJvt79024621@ratthing-b246.strakt.com> References: <20040615165607.GA19656@vicky.ecs.soton.ac.uk> <20040615181350.GP19360@solar.trillke> <200406151923.i5FJNeEt024559@ratthing-b246.strakt.com> <20040615193245.GQ19360@solar.trillke> <200406151957.i5FJvt79024621@ratthing-b246.strakt.com> Message-ID: <20040615200509.GR19360@solar.trillke> [Laura Creighton Tue, Jun 15, 2004 at 09:57:55PM +0200] > >Something else: It would be good if you switched to working on > >the trunk-version of PyPy. The branch/src-newobjectmodel is basically > >out of order and has been merged back into the trunk on the sunday > >before EuroPython 2004. (You can see where you are via "svn info" > >in e.g. the src/ directory). > > I'm not there. I'm in http://codespeak.net/svn/pypy/branch/src-new-utest/pypy/tool > and I made that branch the thursday or Friday after EP. Do you want me to > move? No, i guess that's fine although the tool itself could certainly live on the trunk as well. The branch is only really needed when actually going for the conversion and it usually is easier to open branches just for short timeframes to reduce merging complexity. Btw, I hope i will find some time later this week to work on the remaining utest-issues other than the assertion-conversions. cheers, holger From hpk at trillke.net Tue Jun 15 23:17:17 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 15 Jun 2004 23:17:17 +0200 Subject: [pypy-dev] Re: stuff In-Reply-To: <2mekogajqw.fsf@starship.python.net> References: <2mn034ann3.fsf@starship.python.net> <20040615145854.GJ19360@solar.trillke> <2misdsal0v.fsf@starship.python.net> <20040615160029.GL19360@solar.trillke> <2mekogajqw.fsf@starship.python.net> Message-ID: <20040615211717.GW19360@solar.trillke> [Michael Hudson Tue, Jun 15, 2004 at 05:06:31PM +0100] > holger krekel writes: > > > [Michael Hudson Tue, Jun 15, 2004 at 04:38:56PM +0100] > >> holger krekel writes: > >> > [Michael Hudson Tue, Jun 15, 2004 at 03:42:24PM +0100] > >> > I think you could put a _stringhelper.py into appspace and use that > >> > from the app-level definition of app_mod__String_ANY IIUC. > >> > >> Guess so, but I don't think we have the equivalent of > >> PyImport_ImportModule() yet, do we? > > > > no. But you need to have that app_mod__String_ANY thingie, anyway > > and can import from there, as far as i see. > > Oh yeah :-) Actually, some ImportModule function at interp-level would be nice. Hum, OTOH i don't see why space.builtin.__import__ wouldn't work :-) > >> > Note that these days, apart from Files and wholly-wrapped cpython-modules, we > >> > don't have all that many cpythonobject-wrapped thingies around, anymore. > >> > >> True. > > > > so maybe it's not worth the effort to seriously think about it if we > > are only talking abut Files? > > Maybe not. But it might help for other extension types, too... sorry for asking a possibly dumb question: what/which do you mean with extension types? Something like socket and friends? cheers, holger From hpk at trillke.net Wed Jun 16 22:52:59 2004 From: hpk at trillke.net (holger krekel) Date: Wed, 16 Jun 2004 22:52:59 +0200 Subject: [pypy-dev] getting rid of multimethods? Message-ID: <20040616205259.GH19360@solar.trillke> Hi, we just had a short IRC-discussion about the possibility of getting rid of multimethods alltogether. Note [*], that during the EuroPython 2004-Sprint in Gothenburg we introduced "descriptors" much as they are used in CPython. This allows us to cleanly expose "internal" objects like functions, code, module and frame objects with e.g. proper __dict__ and __class__ descriptors. Both the standard and the trivial object space now work with descriptors (see objspace/descroperation.py). The internal descriptors are defined in interpreter/typedef.py. As a side effect you can now run "py.py -S py.py" i.e. pypy on the standard object space runs pypy on trivial object space! (Be sure to have recent hardware and/or make yourself some coffee if you actually run this :-) However, "multimethods" are still used for building descriptors for basic types. The question arises if we still need multimethods at all. If we wouldn't use them we would probably have to hand-code a few type-switches inside e.g. list-descr__setitem__ for slices and such but those would be rather explicit and easier to understand than the multimethod business (for me at least :-). Any opinions? I think it's better to discuss this idea here on pypy-dev some more than just on IRC ... cheers, holger [*] Sorry that there wasn't any EP2004 sprint report up to now. I take the opportunity to quickly report about the main result of the sprint. From arigo at tunes.org Thu Jun 17 00:23:52 2004 From: arigo at tunes.org (Armin Rigo) Date: Wed, 16 Jun 2004 23:23:52 +0100 Subject: [pypy-dev] py.py -S -i -- py.py -S Message-ID: <20040616222352.GA20791@vicky.ecs.soton.ac.uk> Hi ! Starting from tonight, PyPy -S can run itself. Cheers ! It only takes one or two hours to start up... And less than a minute to compute 2+3 :-) A bientot, Armin. From lac at strakt.com Thu Jun 17 08:00:37 2004 From: lac at strakt.com (Laura Creighton) Date: Thu, 17 Jun 2004 08:00:37 +0200 Subject: [pypy-dev] having broken the back of the unittest conversion problem ... Message-ID: <200406170600.i5H60bdf010625@theraft.strakt.com> I now need a bit more help. I made this file. Thanks, Laura """ I've been looking at unittest.py, and I have a few questions. First - is this conversion table ok as far as it goes? Second - do we ever use the msg argument, or always the None default? Third - what about the ones I left out? what is the 'raises' syntax? Fourth - do we ever use them without a preceeding self. ? Fifth - what about the imports? we need to convert them too. import unittest --> from std.utest import raises, whatelse ? """ # The translations needed, in ascending order of my confusion #def assert_(self, expr, msg=None): self.assert_(expr) --> assert expr self.failUnless(expr) --> assert expr #def assertEqual(self, first, second, msg=None): self.assertEqual(left, right) --> assert left == right self.assertEquals(left, right) --> assert left == right self.failUnlessEqual(left, right) --> assert left == right #def assertNotEqual(self, first, second, msg=None): self.assertNotEqual(left, right) --> assert left != right self.assertNotEquals(left, right) --> assert left != right self.failIfEqual(left, right) --> assert left != right # I don't know the precise syntax for raises #def assertRaises(self, excClass, callableObj, *args, **kwargs): self.assertRaises(excClass, callableObj, *args, **kwargs) --> raises(ExpectedException, 'now what?', 'now what2?') self.failUnlessRaises(excClass, callableObj, *args, **kwargs) --> raises(ExpectedException, 'now what?', 'now what2?') # I don't know if the new framework handles these at all, or their # new names if they exist #def fail(self, msg=None): #def failIf(self, expr, msg=None): #def failUnless(self, expr, msg=None): # And I am even more clueless about what you want me to do # about these friends. #def failUnlessAlmostEqual(self, first, second, places=7, msg=None): #assertAlmostEqual = assertAlmostEquals = failUnlessAlmostEqual #def failIfAlmostEqual(self, first, second, places=7, msg=None): #assertNotAlmostEqual = assertNotAlmostEquals = failIfAlmostEqual From lac at strakt.com Thu Jun 17 08:10:41 2004 From: lac at strakt.com (Laura Creighton) Date: Thu, 17 Jun 2004 08:10:41 +0200 Subject: [pypy-dev] getting rid of multimethods? In-Reply-To: Message from holger krekel of "Wed, 16 Jun 2004 22:52:59 +0200." <20040616205259.GH19360@solar.trillke> References: <20040616205259.GH19360@solar.trillke> Message-ID: <200406170610.i5H6Afng011701@theraft.strakt.com> There is a niceness about how the multimethods group everything in one place. Assuming we ever want to run more than one object space at the same time, or more than one representation of a given type, how would we structure things so that we don't just have 'a handful of stuff over here, and then some more from over there' ... ? Laura From hpk at trillke.net Thu Jun 17 08:44:42 2004 From: hpk at trillke.net (holger krekel) Date: Thu, 17 Jun 2004 08:44:42 +0200 Subject: [pypy-dev] having broken the back of the unittest conversion problem ... In-Reply-To: <200406170600.i5H60bdf010625@theraft.strakt.com> References: <200406170600.i5H60bdf010625@theraft.strakt.com> Message-ID: <20040617064442.GJ19360@solar.trillke> Morning Laura, [Laura Creighton Thu, Jun 17, 2004 at 08:00:37AM +0200] > I now need a bit more help. I made this file. > Thanks, Laura > > """ > I've been looking at unittest.py, and I have a few questions. > First - is this conversion table ok as far as it goes? yes. > Second - do we ever use the msg argument, or always the None default? i think we use it only in a few places if any. If i see it correctly then honoring the msg would kill your/Armin's approach of looking for the significant comma. Or is there a simple solution? So i guess the approach should be to forget about it and see if anything screws up. > Third - what about the ones I left out? what is the 'raises' syntax? actually the same syntax as with assertRaises. So assertRaises should basically be a simple replace('assertRaises', 'raises'). > Fourth - do we ever use them without a preceeding self. ? no, don't worry. this is hardly feasible. > Fifth - what about the imports? we need to convert them too. > import unittest --> from std.utest import raises, whatelse ? i think you don't need to change the imports because we usually import 'pypy.tool.testit' not unittest directly. We will have to do some more stuff for testit.AppTestCases etc.pp. For simplicity of the automatic conversion we can just continue to do it the old way (as opposed to prefix all app-tests with app_test_, which can be converted separately if needed). > #def assert_(self, expr, msg=None): > self.assert_(expr) --> assert expr > self.failUnless(expr) --> assert expr > > #def assertEqual(self, first, second, msg=None): > self.assertEqual(left, right) --> assert left == right > self.assertEquals(left, right) --> assert left == right > self.failUnlessEqual(left, right) --> assert left == right > > #def assertNotEqual(self, first, second, msg=None): > self.assertNotEqual(left, right) --> assert left != right > self.assertNotEquals(left, right) --> assert left != right > self.failIfEqual(left, right) --> assert left != right right. (Isn't the number of aliases incredible?) > # I don't know the precise syntax for raises > > #def assertRaises(self, excClass, callableObj, *args, **kwargs): > self.assertRaises(excClass, callableObj, *args, **kwargs) > --> raises(ExpectedException, 'now what?', 'now what2?') > raises(excClass, callableObj, *args, **kwargs) > self.failUnlessRaises(excClass, callableObj, *args, **kwargs) > --> raises(ExpectedException, 'now what?', 'now what2?') raises(excClass, callableObj, *args, **kwargs) > #def fail(self, msg=None): doesn't exist in utest but will have to be re-added because we apparently use this in a few places. Probably with 'from std.utest import fail'. > #def failIf(self, expr, msg=None): assert not expr > #def failUnless(self, expr, msg=None): assert expr > # And I am even more clueless about what you want me to do > # about these friends. > > #def failUnlessAlmostEqual(self, first, second, places=7, msg=None): > #assertAlmostEqual = assertAlmostEquals = failUnlessAlmostEqual > > #def failIfAlmostEqual(self, first, second, places=7, msg=None): > #assertNotAlmostEqual = assertNotAlmostEquals = failIfAlmostEqual these are new in python2.3 IIRC and can be (if we use it at all) converted to: assert round(first-second, 7) == 0 and assert round(first-second, 7) != 0 respectively. cheers, holger From arigo at tunes.org Thu Jun 17 10:19:39 2004 From: arigo at tunes.org (Armin Rigo) Date: Thu, 17 Jun 2004 09:19:39 +0100 Subject: [pypy-dev] having broken the back of the unittest conversion problem ... In-Reply-To: <20040617064442.GJ19360@solar.trillke> References: <200406170600.i5H60bdf010625@theraft.strakt.com> <20040617064442.GJ19360@solar.trillke> Message-ID: <20040617081938.GA28289@vicky.ecs.soton.ac.uk> Hello! On Thu, Jun 17, 2004 at 08:44:42AM +0200, holger krekel wrote: > > self.assertNotEquals(left, right) --> assert left != right > > self.failIfEqual(left, right) --> assert left != right Maybe for consistency we should really use the operator implied in the name, i.e.: self.assertNotEquals(left, right) --> assert left != right self.failIfEqual(left, right) --> assert not (left == right) Just in case we really check specifically the __eq__ or __ne__ operators. > > #def fail(self, msg=None): > > doesn't exist in utest but will have to be re-added because we apparently > use this in a few places. Probably with 'from std.utest import fail'. raise AssertionError could be the equivalent. Armin From hpk at trillke.net Thu Jun 17 10:32:33 2004 From: hpk at trillke.net (holger krekel) Date: Thu, 17 Jun 2004 10:32:33 +0200 Subject: [pypy-dev] having broken the back of the unittest conversion problem ... In-Reply-To: <20040617081938.GA28289@vicky.ecs.soton.ac.uk> References: <200406170600.i5H60bdf010625@theraft.strakt.com> <20040617064442.GJ19360@solar.trillke> <20040617081938.GA28289@vicky.ecs.soton.ac.uk> Message-ID: <20040617083233.GK19360@solar.trillke> [Armin Rigo Thu, Jun 17, 2004 at 09:19:39AM +0100] > Hello! > > On Thu, Jun 17, 2004 at 08:44:42AM +0200, holger krekel wrote: > > > self.assertNotEquals(left, right) --> assert left != right > > > self.failIfEqual(left, right) --> assert left != right > > Maybe for consistency we should really use the operator implied in the name, > i.e.: > > self.assertNotEquals(left, right) --> assert left != right > self.failIfEqual(left, right) --> assert not (left == right) In unittest.py they all map to the same thing. IOW, you can't expect much from unittest's name usage, anyway, so i wouldn't try to be too clever there ... > Just in case we really check specifically the __eq__ or __ne__ operators. > > > > #def fail(self, msg=None): > > > > doesn't exist in utest but will have to be re-added because we apparently > > use this in a few places. Probably with 'from std.utest import fail'. > > raise AssertionError could be the equivalent. good point! btw, do you also have a solution for the 'msg' third parameter problem with respect to the easy-parsing approach? I'd like to have a generic converter script for unittest->utest at some point and it would be nice if it tried to do as much as possible ... i tend to (again) think that AST is a somewhat cleaner solution. holger From mwh at python.net Thu Jun 17 11:03:05 2004 From: mwh at python.net (Michael Hudson) Date: Thu, 17 Jun 2004 10:03:05 +0100 Subject: [pypy-dev] Re: stuff References: <2mn034ann3.fsf@starship.python.net> <20040615145854.GJ19360@solar.trillke> <2misdsal0v.fsf@starship.python.net> <20040615160029.GL19360@solar.trillke> <2mekogajqw.fsf@starship.python.net> <20040615211717.GW19360@solar.trillke> Message-ID: <2mwu268sl2.fsf@starship.python.net> holger krekel writes: >> >> > Note that these days, apart from Files and wholly-wrapped cpython-modules, we >> >> > don't have all that many cpythonobject-wrapped thingies around, anymore. >> >> >> >> True. >> > >> > so maybe it's not worth the effort to seriously think about it if we >> > are only talking abut Files? >> >> Maybe not. But it might help for other extension types, too... > > sorry for asking a possibly dumb question: what/which do you mean with > extension types? Something like socket and friends? Yes. Cheers, mwh -- This is not to say C++ = bad, Lisp = good. It's to say C++ = bad irrespective of everything else. -- Alain Picard, comp.lang.lisp From mwh at python.net Thu Jun 17 11:05:52 2004 From: mwh at python.net (Michael Hudson) Date: Thu, 17 Jun 2004 10:05:52 +0100 Subject: [pypy-dev] Re: having broken the back of the unittest conversion problem ... References: <200406170600.i5H60bdf010625@theraft.strakt.com> <20040617064442.GJ19360@solar.trillke> Message-ID: <2msmcu8sgf.fsf@starship.python.net> holger krekel writes: >> # And I am even more clueless about what you want me to do >> # about these friends. >> >> #def failUnlessAlmostEqual(self, first, second, places=7, msg=None): >> #assertAlmostEqual = assertAlmostEquals = failUnlessAlmostEqual >> >> #def failIfAlmostEqual(self, first, second, places=7, msg=None): >> #assertNotAlmostEqual = assertNotAlmostEquals = failIfAlmostEqual > > these are new in python2.3 IIRC and can be (if we use it at all) > converted to: > > assert round(first-second, 7) == 0 > > and > > assert round(first-second, 7) != 0 > > respectively. If we use these at all, I'd like to have words with whoever introduced the usage :-) Mutter mutter, fp-induced paranoia, ... Cheers, mwh -- If you have too much free time and can't think of a better way to spend it than reading Slashdot, you need a hobby, a job, or both. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq From arigo at tunes.org Thu Jun 17 13:46:38 2004 From: arigo at tunes.org (Armin Rigo) Date: Thu, 17 Jun 2004 12:46:38 +0100 Subject: [pypy-dev] having broken the back of the unittest conversion problem ... In-Reply-To: <20040617083233.GK19360@solar.trillke> References: <200406170600.i5H60bdf010625@theraft.strakt.com> <20040617064442.GJ19360@solar.trillke> <20040617081938.GA28289@vicky.ecs.soton.ac.uk> <20040617083233.GK19360@solar.trillke> Message-ID: <20040617114638.GA26874@vicky.ecs.soton.ac.uk> Hello Holger, On Thu, Jun 17, 2004 at 10:32:33AM +0200, holger krekel wrote: > btw, do you also have a solution for the 'msg' third parameter problem with > respect to the easy-parsing approach? Sure, the same trick works: find the first "," so that whatever is left to it parses successfully; this is the first arg. Then repeat with the rest. This way, any number of arguments can be safely extracted. Armin From hpk at trillke.net Thu Jun 17 22:50:31 2004 From: hpk at trillke.net (holger krekel) Date: Thu, 17 Jun 2004 22:50:31 +0200 Subject: [pypy-dev] having broken the back of the unittest conversion problem ... In-Reply-To: <20040617114638.GA26874@vicky.ecs.soton.ac.uk> References: <200406170600.i5H60bdf010625@theraft.strakt.com> <20040617064442.GJ19360@solar.trillke> <20040617081938.GA28289@vicky.ecs.soton.ac.uk> <20040617083233.GK19360@solar.trillke> <20040617114638.GA26874@vicky.ecs.soton.ac.uk> Message-ID: <20040617205031.GM19360@solar.trillke> [Armin Rigo Thu, Jun 17, 2004 at 12:46:38PM +0100] > Hello Holger, > > On Thu, Jun 17, 2004 at 10:32:33AM +0200, holger krekel wrote: > > btw, do you also have a solution for the 'msg' third parameter problem with > > respect to the easy-parsing approach? > > Sure, the same trick works: find the first "," so that whatever is left to it > parses successfully; this is the first arg. Then repeat with the rest. This > way, any number of arguments can be safely extracted. oh sure! holger From hpk at trillke.net Sat Jun 19 11:23:37 2004 From: hpk at trillke.net (holger krekel) Date: Sat, 19 Jun 2004 11:23:37 +0200 Subject: [pypy-dev] joeq! pypy goes jython? Message-ID: <20040619092337.GA19809@solar.trillke> hi pypyers, Jens-Uwe Mager pointed me to an early interesting paper about a JavaInJava implementation done by a Sun researcher: http://research.sun.com/techrep/1998/smli_tr-98-64.pdf However, there is no code available, let alone under a free license. So i started looking around a bit more. And i found ... joeq! This is a real available Java/Java implementation which is an LGPL-project on sourceforge: http://joeq.sourceforge.net/ and has a very nice overview http://joeq.sourceforge.net/ivme03/ joeq supports hosted (on top of another JVM) *and* native execution at least on linux and windows and supports threads, memory management, scheduling and ELF-handling. So here are some more information bits i collected from a frist walk through the documentation and the above paper. joeq uses a so called QUAD intermediate representation which has some similarities to our flow-graph representation. It has assembler backends (that work from the QUAD and a Bytecode representation) which "generate metadata about the code, such as reference maps for garbage collection, exception tables, line numbers for debugging and generating exception tracebacks, and the locations of heap and code references in the code. This metadata is used by the runtime system and garbage collector, and to support code relocation." Joeq also includes a Memory manager with Heap and Stack abstractions and allowing differenc GC-strategies. Also, it seems to support in-process compilation and execution! Btw, joeq is written by John Whaley who also took part in the Jalapeno efforts and he really seems to know what he is doing. All i all, i think that we probably want to checkout joeq some more. In particular, we might want to think about trying to generate a QUAD representation of PyPy and reuse some of the joeq infrastructure. We can expect to have less integration issues than with the Low-Level-Virtual-Machine (LLVM) project which is written in C++ (ever worked with C++-libraries and dependencies? funfunfun). So, what about running PyPy in Jython, anyway? Yes, i know that Jython does not yet fully support new-style classes and all, but ASFAIK Samuele already put out an alpha-release and it has to be done anyway :-) Of course, at a later stage, we can always rewrite parts of joeq in plain Python :-) All things considered, i don't know how active the joeq project is. We should want to write John Whaley a mail inquiring some more about the current state of the joeq project. At last, I can't help but quote a funny random bit from the joeq paper: We also explicitly include the implicit ``this'' parameter in the parameter list for instance methods, so code can treat method parameters uniformly. :-) cheers and a nice weekend, holger From Guenter.Jantzen at t-mobile.de Tue Jun 22 12:06:01 2004 From: Guenter.Jantzen at t-mobile.de (=?iso-8859-1?Q?=22Jantzen=2C_G=FCnter=22?=) Date: Tue, 22 Jun 2004 12:06:01 +0200 Subject: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6 Message-ID: Holger Krekel wrote: > > All i all, i think that we probably want to checkout joeq > some more. In particular, we might want to think about > trying to generate a QUAD representation of PyPy and reuse > some of the joeq infrastructure. We can expect to have less > integration issues than with the Low-Level-Virtual-Machine > (LLVM) project which is written in C++ (ever worked with > C++-libraries and dependencies? funfunfun). > C++ is an Industry standard based on C. C++ Libraries can be wrapped by C-Libraries (extern 'C') if you have the source-code at hand. C++ Libraries that are not wrapped can contain native C++ (for example class definitions). Then they can be called by C++ code only. It is not possible to call C++ Libraries which are compiled with a different Compiler, because all C++ Implementations have different naming conventions for methods and parameters(name mangling). I don't say LLVM is better for PyPy than joeq. But I think it should be first considered what is right and second what is easy to implement. regards Guenter From anthony at interlink.com.au Tue Jun 22 12:10:36 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Tue, 22 Jun 2004 20:10:36 +1000 Subject: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6 In-Reply-To: References: Message-ID: <40D8059C.1060900@interlink.com.au> Jantzen, G?nter wrote: > Holger Krekel wrote: > >>All i all, i think that we probably want to checkout joeq >>some more. In particular, we might want to think about >>trying to generate a QUAD representation of PyPy and reuse >>some of the joeq infrastructure. We can expect to have less >>integration issues than with the Low-Level-Virtual-Machine >>(LLVM) project which is written in C++ (ever worked with >>C++-libraries and dependencies? funfunfun). >> > > > C++ is an Industry standard based on C. > C++ Libraries can be wrapped by C-Libraries (extern 'C') if you have the source-code at hand. > C++ Libraries that are not wrapped can contain native C++ (for example class definitions). > Then they can be called by C++ code only. It is not possible to call C++ Libraries > which are compiled with a different Compiler, because all C++ Implementations have different naming conventions > for methods and parameters(name mangling). > > I don't say LLVM is better for PyPy than joeq. But I think it should be first considered what > is right and second what is easy to implement. Huh? This is completely ass-backwards. Trying to implement it in C++, merely because it's "an industry standard", is about the worst reason in the world. And in your reply you point out that the "industry standard" is a shambles when it comes to dependencies and libraries. Consider what works, then worry about what's got some supposed "industry standard" elephant stamp on it. If we worried about "industry standards" we'd be all implementing in ECMAScript, Java, and C#, _not_ Python. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From Guenter.Jantzen at t-mobile.de Tue Jun 22 13:36:15 2004 From: Guenter.Jantzen at t-mobile.de (=?iso-8859-1?Q?=22Jantzen=2C_G=FCnter=22?=) Date: Tue, 22 Jun 2004 13:36:15 +0200 Subject: AW: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6 Message-ID: > Anthony Baxter wrote: > Jantzen, G?nter wrote: > > Holger Krekel wrote: > > > >>All i all, i think that we probably want to checkout joeq > >>some more. In particular, we might want to think about > >>trying to generate a QUAD representation of PyPy and reuse > >>some of the joeq infrastructure. We can expect to have less > >>integration issues than with the Low-Level-Virtual-Machine > >>(LLVM) project which is written in C++ (ever worked with > >>C++-libraries and dependencies? funfunfun). > >> > > > > > > C++ is an Industry standard based on C. > > C++ Libraries can be wrapped by C-Libraries (extern 'C') if > you have the source-code at hand. > > C++ Libraries that are not wrapped can contain native C++ > (for example class definitions). > > Then they can be called by C++ code only. It is not > possible to call > > C++ Libraries which are compiled with a different Compiler, because > > all C++ Implementations have different naming conventions > for methods > > and parameters(name mangling). > > > > I don't say LLVM is better for PyPy than joeq. But I think > it should > > be first considered what > > is right and second what is easy to implement. > > Huh? This is completely ass-backwards. Trying to implement it > in C++, merely because it's "an industry standard", is about > the worst reason in the world. And in your reply you point > out that the "industry standard" is a shambles when it comes > to dependencies and libraries. > > Consider what works, then worry about what's got some > supposed "industry standard" elephant stamp on it. If we > worried about "industry standards" we'd be all implementing > in ECMAScript, Java, and C#, _not_ Python. I did not suggest to implement something in C++ I only suggested to search for better reasons to make a decision. When choosing a library for a backend you will always have integration issues. It is never a fun to cross language borders. But as long as you wourk with 'industry standards' like Java, C or C++ you have a good chance to solve this problem one time and to encapsulate this stuff with a thin wrapper. For this reason it is more important to look from a design perspective. When choosing a backend, ask yourself if it will support the features which are your needs. I am not a native speaker, so I don't understand the expression 'ass-backwards'. Seems not very polite to me. regards Guenter From hpk at trillke.net Tue Jun 22 15:51:01 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 22 Jun 2004 15:51:01 +0200 Subject: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6 In-Reply-To: References: Message-ID: <20040622135101.GM19360@solar.trillke> ["Jantzen, G?nter" Tue, Jun 22, 2004 at 01:36:15PM +0200] > > Anthony Baxter wrote: > > Consider what works, then worry about what's got some > > supposed "industry standard" elephant stamp on it. If we > > worried about "industry standards" we'd be all implementing > > in ECMAScript, Java, and C#, _not_ Python. > > I did not suggest to implement something in C++ > I only suggested to search for better reasons to make a decision. > > When choosing a library for a backend you will always have integration issues. Indeed. > It is never a fun to cross language borders. But as long as you wourk with > 'industry standards' like Java, C or C++ you have a good chance to solve this problem > one time and to encapsulate this stuff with a thin wrapper. Well, to my ears an "industry standard" is usually the label vendors put on their product. Moreover, with PyPy we cross language borders all the time. It is inherent to the kind of project we are doing. For practical matters, integration issues and the "consider that works" principle are very important to our kind of evolutionary development. Anyway, i imagine that if we use joeq or LLVM as a backend we might very well rewrite the most interesting parts in Python at some point, depending on our experiences and the actual development. But for now, it's "does it do the job" and "does it integrate well enough". > For this reason it is more important to look from a design perspective. I think we do but use a different definition of "design" then what is considered "design" in large companies which usually develop in terms of UML diagrams, workflow specifications/engines and model-driven code-generators using "standard" components etc.pp. No offense meant :-) > When choosing a backend, ask yourself if it will support the features which are your needs. OK, i guess we all agree here. > I am not a native speaker, so I don't understand the expression 'ass-backwards'. > Seems not very polite to me. I am not a native speaker myself but i would think this is a just a somewhat stronger word for "backwards". just my 2ec. cheers, holger From Guenter.Jantzen at t-mobile.de Tue Jun 22 16:51:31 2004 From: Guenter.Jantzen at t-mobile.de (=?iso-8859-1?Q?=22Jantzen=2C_G=FCnter=22?=) Date: Tue, 22 Jun 2004 16:51:31 +0200 Subject: AW: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6 Message-ID: Holger Krekel wrote: > Well, to my ears an "industry standard" is usually the label > vendors put on their product. Moreover, with PyPy we cross > language borders all the time. It is inherent to the kind of > project we are doing. For practical matters, integration > issues and the "consider that works" principle are very > important to our kind of evolutionary development. Of course. My first mail was not very clear in this point. I said "industry standard", but what I meant was 'a reliable and well known language' in which we can trust so far that it is not necessary to discuss bitfiddling details in the first place. Scott Myers, author of 'Effective C++' titled one chapter 'Say what you mean; understand what you're saying' ;-)) I will try to be more clear for avoiding unecessary disaccord. > Anyway, i imagine that if we use joeq or LLVM as a backend we > might very well rewrite the most interesting parts in Python > at some point, depending on our experiences and the actual > development Sounds to me just like a somewhat stronger word for *forward* :-))) Cheers Guenter From anthony at interlink.com.au Tue Jun 22 17:17:36 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Wed, 23 Jun 2004 01:17:36 +1000 Subject: AW: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6 In-Reply-To: References: Message-ID: <40D84D90.5090705@interlink.com.au> Jantzen, G?nter wrote: > I am not a native speaker, so I don't understand the expression 'ass-backwards'. > Seems not very polite to me. It's just a slightly stronger way of saying "the wrong way". I'm Australian, and tend to use language like a blunt instrument. Apologies for any offense. From Guenter.Jantzen at t-mobile.de Tue Jun 22 17:38:20 2004 From: Guenter.Jantzen at t-mobile.de (=?iso-8859-1?Q?=22Jantzen=2C_G=FCnter=22?=) Date: Tue, 22 Jun 2004 17:38:20 +0200 Subject: AW: AW: [pypy-dev] AW: pypy-dev Digest, Vol 287, Issue 6 Message-ID: Anthony Baxter wrote: > Jantzen, G?nter wrote: > > I am not a native speaker, so I don't understand the expression > > 'ass-backwards'. Seems not very polite to me. > > It's just a slightly stronger way of saying "the wrong way". > I'm Australian, and tend to use language like a blunt > instrument. Apologies for any offense. > Blunt is better than overly polite. :-) From arigo at tunes.org Wed Jun 23 18:01:45 2004 From: arigo at tunes.org (Armin Rigo) Date: Wed, 23 Jun 2004 17:01:45 +0100 Subject: [pypy-dev] getting rid of multimethods? In-Reply-To: <200406170610.i5H6Afng011701@theraft.strakt.com> References: <20040616205259.GH19360@solar.trillke> <200406170610.i5H6Afng011701@theraft.strakt.com> Message-ID: <20040623160145.GA3028@vicky.ecs.soton.ac.uk> Hello, On Thu, Jun 17, 2004 at 08:10:41AM +0200, Laura Creighton wrote: > There is a niceness about how the multimethods group everything in one > place. Yes, their declarativeness is nice. I don't think we should remove them, but maybe we should move them away from run-time. It would be possible to use the multimethod declarations only to generate Python sources with the descriptors (i.e. the __add__&co methods). The type switches would be generated too. This is basically what Holger suggested for descroperation.py already. I still think that it is overkill for descroperation.py, but for multimethods it would be helpful as a check, or if you prefer reading the generated Python source instead of the multimethod.py magic. A bientot, Armin From arigo at tunes.org Thu Jun 24 21:47:27 2004 From: arigo at tunes.org (Armin Rigo) Date: Thu, 24 Jun 2004 20:47:27 +0100 Subject: [pypy-dev] Summary Message-ID: <20040624194727.GA21690@vicky.ecs.soton.ac.uk> Hello ! Here is at least a quick overview of the sprint changes... * Holger already talked about the big change, which was to use CPython's descriptor model as the object model. Now all classes, built-in or not, have a bunch of __xxx__ methods and properties, and the operations themselves (e.g. space.add()) are no longer multimethods but calls to these special methods, using CPython's rules, which you can see in objspace/descroperation.py. For example, space.add(w1,w2) works by looking up __add__ on the type of w1 and then __radd__ on the type of w2. This means that there isn't a lot of difference any more between built-in and user-defined classes, which is good. Note that multimethods are still used to populate the built-in classes, e.g. int.__add__() is created as a function object that dispatches to one of the add__Int_Xxx() functions. So basically every complex meta-class magic works just fine in PyPy now :-) Credits in alphabetical order: Holger, me, Michael, Samuele. * Samuele and Alex (and Holger on tests) implemented the package import system. * On the translator side, Anders and myself worked on code generation: it can produce things like classes with methods on them. Then Anders cleaned it up a lot and refactored the corresponding files and tests. Holger helped here too. * Anna worked on documentation. * We considered the unittest-to-utest switch a couple of time. utest seems ready now. At the end of the second week Laura and Jacob started working on an automatic translation tool for all our test_*.py files. Laura seems to have almost finished it by now. * Michael and Holger have put an (optional) HTTP server in PyPy, to handle these long tracebacks in a browser. I think it is still waiting for improvement. * A lot of small things went fixed all along the sprint, notaby by trying to run PyPy on top of itself. * Holger moved 'class complex' into __builtin__module.py. * Alex, Holger, Michael: String formatting ( % ) is done by PyPy now; I think it's not entierely complete yet. * Laura worked a bit more on her tool to figure out what exactly is missing but present in CPython. * We now have real CPython-ish hash-tables as dictionaries. Thanks Michael. * A nice feature (XXX mention it somewhere) is that on the PyPy prompt, Ctrl-C sends you to a CPython prompt in which you can play with PyPy at interp-level. All app-level names 'x' are available under 'w_x' names, i.e. the same name with a 'w_' prefix, and of course there is a 'space'. * Holger, Michael: operator module in pure Python. [However, Michael, let me point out that 'operator.add(2,3)' fails currently -- all of them do. staticmethods are not callable.] Sorry if I missed something above the "detail" level, or someone's due credits. This list was built by scanning through the svn checkin messages. A bient?t, Armin. From tismer at stackless.com Fri Jun 25 02:47:42 2004 From: tismer at stackless.com (Christian Tismer) Date: Fri, 25 Jun 2004 02:47:42 +0200 Subject: [pypy-dev] getting rid of multimethods? In-Reply-To: <20040623160145.GA3028@vicky.ecs.soton.ac.uk> References: <20040616205259.GH19360@solar.trillke> <200406170610.i5H6Afng011701@theraft.strakt.com> <20040623160145.GA3028@vicky.ecs.soton.ac.uk> Message-ID: <40DB762E.4050105@stackless.com> Armin Rigo wrote: > Hello, > > On Thu, Jun 17, 2004 at 08:10:41AM +0200, Laura Creighton wrote: > >>There is a niceness about how the multimethods group everything in one >>place. > > > Yes, their declarativeness is nice. I don't think we should remove them, but > maybe we should move them away from run-time. > > It would be possible to use the multimethod declarations only to generate > Python sources with the descriptors (i.e. the __add__&co methods). The type > switches would be generated too. > > This is basically what Holger suggested for descroperation.py already. I > still think that it is overkill for descroperation.py, but for multimethods it > would be helpful as a check, or if you prefer reading the generated Python > source instead of the multimethod.py magic. In a way, turning multi-methods into a meta-class like concept that instantiates __add__ things on type creation time? Sounds like a good compromize. ciao - chris -- Christian Tismer :^) Mission Impossible 5oftware : 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 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From arigo at tunes.org Fri Jun 25 18:18:18 2004 From: arigo at tunes.org (Armin Rigo) Date: Fri, 25 Jun 2004 17:18:18 +0100 Subject: [pypy-dev] fun with functions Message-ID: <20040625161818.GA27928@vicky.ecs.soton.ac.uk> Hello, I'm reworking argument dispatching code, and I realize that we've always had a funny problem. In CPython, we have the following half-expected behavior: class X: def f(self, **kwds): print kwds x = X() x.f(v=5) -> {'v': 5} x.f(self=5) -> TypeError: multiple values for argument 'self' But of course, nothing wrong with: def f(**kwds): print kwds f(self=5) -> {'self': 5} However, this fails in PyPy with the same TypeError as above! The reason is that the call is done via the __call__ descriptor, which is a perfectly normal method: f.__call__ -> (In CPython you get a .) Now if it is a method we can investiate a bit: >>> f.__call__.im_self is f True >>> f.__call__.im_func >>> f.__call__.im_func.func_code >>> f.__call__.im_func.func_code.co_varnames AttributeError: co_varnames but actually, even without (yet) exposing it at app-level, the code object has got a signature which says the function's argument list is (self, *args, **keywords). The name 'self' conflicts here with a 'self' keyword. Ack. It's nice and all to be able to inspect built-in functions' signature (which you cannot do yet, but it's just a matter of adding computed co_xxx attributes on this )... but this is a problem. Moreover, we have a different compatibility problem too: in CPython, built-in functions don't have a __get__, so you can put them in classes and read them out without having the first argument bound to the instance. For example, if you put 'operator.add' in the class TrivialObjSpace, then 'space.add' is exactly 'operator.add' and not a bound version of it. What should we do about it? Maybe asking python-dev for guidance? Have 'unboundable function objects' -- like staticmethod, but the latter is not callable -- and make some carefully selected functions unboundable for compatibility? For the 1st problem we could force a general solution by saying that the argument that a method binds is hidden to keywords. It would also make the very first example of this e-mail work, although it doesn't work in CPython. A bientot, Armin. From hpk at trillke.net Sat Jun 26 13:04:39 2004 From: hpk at trillke.net (holger krekel) Date: Sat, 26 Jun 2004 13:04:39 +0200 Subject: [pypy-dev] fun with functions In-Reply-To: <20040625161818.GA27928@vicky.ecs.soton.ac.uk> References: <20040625161818.GA27928@vicky.ecs.soton.ac.uk> Message-ID: <20040626110439.GM19360@solar.trillke> Hi Armin, [Armin Rigo Fri, Jun 25, 2004 at 05:18:18PM +0100] > Moreover, we have a different compatibility problem too: in CPython, built-in > functions don't have a __get__, so you can put them in classes and read them > out without having the first argument bound to the instance. For example, if > you put 'operator.add' in the class TrivialObjSpace, then 'space.add' is > exactly 'operator.add' and not a bound version of it. > > What should we do about it? Maybe asking python-dev for guidance? We could ask who is relying on this behaviour that builtin functions don't get bound on classes. Or maybe just ask who even *knows* it let alone relies on it :-) > Have 'unboundable function objects' -- like staticmethod, but the latter is not > callable -- and make some carefully selected functions unboundable for > compatibility? only if need be. Can you think of any real world use case? > For the 1st problem we could force a general solution by saying that the > argument that a method binds is hidden to keywords. It would also make the > very first example of this e-mail work, although it doesn't work in CPython. Your recent changes (of holding positional and keyword arguments in an Argument instance (nice!)) already implement this. Makes sense. cheers, holger From hpk at trillke.net Sat Jun 26 13:16:59 2004 From: hpk at trillke.net (holger krekel) Date: Sat, 26 Jun 2004 13:16:59 +0200 Subject: [pypy-dev] getting rid of multimethods? In-Reply-To: <20040623160145.GA3028@vicky.ecs.soton.ac.uk> References: <20040616205259.GH19360@solar.trillke> <200406170610.i5H6Afng011701@theraft.strakt.com> <20040623160145.GA3028@vicky.ecs.soton.ac.uk> Message-ID: <20040626111659.GN19360@solar.trillke> [Armin Rigo Wed, Jun 23, 2004 at 05:01:45PM +0100] > Hello, > > On Thu, Jun 17, 2004 at 08:10:41AM +0200, Laura Creighton wrote: > > There is a niceness about how the multimethods group everything in one > > place. > > Yes, their declarativeness is nice. I don't think we should remove them, but > maybe we should move them away from run-time. > > It would be possible to use the multimethod declarations only to generate > Python sources with the descriptors (i.e. the __add__&co methods). The type > switches would be generated too. Might be helpful. > This is basically what Holger suggested for descroperation.py already. I > still think that it is overkill for descroperation.py, but for multimethods it > would be helpful as a check, or if you prefer reading the generated Python > source instead of the multimethod.py magic. Well, in my tree i moved some of the multimethod-declarations (getitem/setitem) for the dictobject into some dict-specific descriptors. I could reuse the existing methods without any modification. It's faster and easier to understand. But i see your point that in other cases the declarativeness of multimethods is nice. But I do think that their existence complicates the understanding of PyPy (at least for me :-). cheers, holger From arigo at tunes.org Sat Jun 26 20:28:10 2004 From: arigo at tunes.org (Armin Rigo) Date: Sat, 26 Jun 2004 19:28:10 +0100 Subject: [pypy-dev] fun with functions In-Reply-To: <20040626110439.GM19360@solar.trillke> References: <20040625161818.GA27928@vicky.ecs.soton.ac.uk> <20040626110439.GM19360@solar.trillke> Message-ID: <20040626182810.GA30566@vicky.ecs.soton.ac.uk> Hello Holger, On Sat, Jun 26, 2004 at 01:04:39PM +0200, holger krekel wrote: > We could ask who is relying on this behaviour that builtin functions don't > get bound on classes. Or maybe just ask who even *knows* it let alone relies > on it :-) > (...) Can you think of any real world use case? PyPy used to store built-ins in the TrivialObjSpace class as operations. I've used it occasionally in situations where hacking was kind of allowed. I don't think any use of that should be regarded as really strong... Armin From tjreedy at udel.edu Sun Jun 27 07:11:32 2004 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 27 Jun 2004 01:11:32 -0400 Subject: [pypy-dev] Re: fun with functions References: <20040625161818.GA27928@vicky.ecs.soton.ac.uk> <20040626110439.GM19360@solar.trillke> Message-ID: "holger krekel" wrote in message news:20040626110439.GM19360 at solar.trillke... > Hi Armin, > > [Armin Rigo Fri, Jun 25, 2004 at 05:18:18PM +0100] > > Moreover, we have a different compatibility problem too: in CPython, built-in > > functions don't have a __get__, so you can put them in classes and read them > > out without having the first argument bound to the instance. For example, if > > you put 'operator.add' in the class TrivialObjSpace, then 'space.add' is > > exactly 'operator.add' and not a bound version of it. > > > > What should we do about it? Maybe asking python-dev for guidance? > > We could ask who is relying on this behaviour that builtin functions don't > get bound on classes. Or maybe just ask who even *knows* it let alone relies > on it :-) >From this user's viewpoint, the fact that CPython's built-in functions do not quite act the same as functions defined in Python itself (and hence need a separate type ) is a bit of a optimization glitch. Breaking the Python function model does occasionally bite people, leading to puzzled queries on c.l.p (Why doesn't this work (with a builtin) when that did (with a true func)? ... Because builtins are not the same...). So I see the possibility of uniform behavior as an advantage. You might look as what Jython does with its builtins (I have no idea). Terry J. Reedy From mwh at python.net Tue Jun 29 15:50:06 2004 From: mwh at python.net (Michael Hudson) Date: Tue, 29 Jun 2004 14:50:06 +0100 Subject: [pypy-dev] Re: Summary References: <20040624194727.GA21690@vicky.ecs.soton.ac.uk> Message-ID: <2mwu1q5v8x.fsf@starship.python.net> Armin Rigo writes: > * Holger, Michael: operator module in pure Python. [However, Michael, let me > point out that 'operator.add(2,3)' fails currently -- all of them do. > staticmethods are not callable.] Argh. Probably not too hard to fix, though... Cheers, mwh -- There are 'infinite' number of developed artifacts and one cannot develop appreciation for them all. It would be all right to not understand something, but it would be imbecilic to put judgements on things one don't understand. -- Xah, comp.lang.lisp From hpk at trillke.net Tue Jun 29 18:51:46 2004 From: hpk at trillke.net (holger krekel) Date: Tue, 29 Jun 2004 18:51:46 +0200 Subject: [pypy-dev] Re: [pypy-svn] r5369 - in pypy/trunk/src/pypy: scripttest scripttest/test tool In-Reply-To: <20040627205328.E1C995ABA5@thoth.codespeak.net> References: <20040627205328.E1C995ABA5@thoth.codespeak.net> Message-ID: <20040629165146.GE30269@solar.trillke> Hi Rocco, [rocco at codespeak.net Sun, Jun 27, 2004 at 10:53:28PM +0200] > Author: rocco > Date: Sun Jun 27 22:53:28 2004 > New Revision: 5369 > > Added: > pypy/trunk/src/pypy/scripttest/ (props changed) > ... > Log: > * tool/app_level_diff.py > > I hacked together a little tool for running a script at app level, and checking > its output against an expected output file. (Sort of like regrtest.py) I added > a feature where the files can be sectioned off into multiple parts, to reduce > disk clutter. > > * scripttest directory I guess this at least should not live directly in src/pypy but in some subdirectory (e.g. tool) or at 'src/scripttest' or something similar. And btw, it's preferable if you talk to some other developer or best to pypy-dev before adding a whole bunch of things :-) > The start of using app_level_diff as a testing tool - I've converted the > CPython regression test test_grammar to it's use. Sectioning is incomplete - > the parts that are sectioned are mainly to isolate failures > > I've also started to do a script made from the examples given in Guido's > tutorial. Incomplete as of now. Can you give some examples of usage? I am a bit of a loss what exactly you are trying to do here. cheers, holger From ben at transversal.com Wed Jun 30 12:08:38 2004 From: ben at transversal.com (Ben Young) Date: Wed, 30 Jun 2004 11:08:38 +0100 Subject: [pypy-dev] Patches? Message-ID: <200406301108.38948.ben@transversal.com> Hi, I have been following the pypy-dev mailing list for some time, as well as maintaining a anon svn checkout of the pypy source and am really excited by this project (in fact it has inspired me to write my own experimental language in python along similar lines!). I was just wondering whether the project is considered stable enough to accept patches and/or bug reports from people who are not directly developers (i.e me!). I have been playing with getting pypy to run some of my own python programs, and although it seems to get pretty close there are a couple of issues. The first is in appspace/operator.py where if you import this in the trivial object space then is gives errors about modifying a dictionary while iterating over it. This can be fixed by the following patch Index: appspace/operator.py =================================================================== --- appspace/operator.py (revision 5402) +++ appspace/operator.py (working copy) @@ -164,7 +164,7 @@ # ugh: import types as _types -for n in globals(): +for n in list(globals()): v = globals()[n] if isinstance(v, _types.FunctionType): globals()[n] = staticmethod(v) The second is in pprint. If you do >>>> import pprint >>>> pprint.pprint([]) you get a massive traceback which I haven't yet quite worked out a fix for. Thanks for your help! Ben Young From lac at strakt.com Wed Jun 30 16:43:25 2004 From: lac at strakt.com (Laura Creighton) Date: Wed, 30 Jun 2004 16:43:25 +0200 Subject: [pypy-dev] utest conversion tool question Message-ID: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com> I am still dizzy and sick, but I am trying to get something done anyhow. I have this question. If you start with self.assertEquals(f(x) + g(x) == q(x), 'Message to print when the assertion fails') you would like things to come back as assert f(x) +\ g(x) == q(x), 'Message to print when the assertion fails' It is the last, optional message which is the sticky part, otherwise you could say, just keep the original parentheses. But this does not work, as the following demonstrates: >>> assert 0 + \ ... 1 == 7, 'no it doesnt' Traceback (most recent call last): File "", line 1, in ? AssertionError: no it doesnt >>> assert (0 + ... 1 == 7, 'no it doesnt') >>> The problem is that once you get into 'backslash pasting' mode, it is hard to know when you should stop. I was working on the assumption that if we have something that works like an expression, but doesn't work when you peal off the parens, i.e. it is multi-line, then you should paste the parens in. And this is mostly correct. But there is this problem. >>> s=''' ... aaa ... bbb ... ccc ... ''' >>> s '\naaa\nbbb\nccc\n' >>> >>> assert ''' ... aaa ... bbb ... ccc ... ''' != s Traceback (most recent call last): File "", line 1, in ? AssertionError >>> thus if I get some code: self.assertNotEquals(''' aaa bbb ccc ''', s) I should not be pasting in the backslashes. But >>> parser.expr(s) Traceback (most recent call last): File "", line 1, in ? File "", line 3 bbb ^ SyntaxError: invalid syntax >>> .... suggestions on how to recognise triple-quoted strings? Apologies if I miss something obvious, my brain isn't really good for much yet. Laura From arigo at tunes.org Wed Jun 30 20:35:14 2004 From: arigo at tunes.org (Armin Rigo) Date: Wed, 30 Jun 2004 19:35:14 +0100 Subject: [pypy-dev] utest conversion tool question In-Reply-To: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com> References: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com> Message-ID: <20040630183514.GA30220@vicky.ecs.soton.ac.uk> Hello Laura, On Wed, Jun 30, 2004 at 04:43:25PM +0200, Laura Creighton wrote: > assert f(x) +\ > g(x) == q(x), 'Message to print when the assertion fails' > > It is the last, optional message which is the sticky part, otherwise you could > say, just keep the original parentheses. There is probably always a way to avoid backslashes. For the above example it would be: assert (f(x) + g(x) == q(x)), 'Message' Inserting these parenthesis shouldn't be too hard if you decompose the arguments anyway. Also note that the same rule applies to each of the two arguments of the assert statement: self.assertEquals(f(x) + g(x) == q(x), 'Message') should, intuitively, get translated to... assert (f(x) + g(x) == q(x)), ( 'Message') I guess once you know the text of each argument to assert, you can check which ones contain a '\n' and add parenthesis in this case. In the above example if the second argument starts right after the original ',' then it should be "\n 'Message'" i.e. including a '\n', so it gets parenthesis too. Armin From hpk at trillke.net Wed Jun 30 20:55:34 2004 From: hpk at trillke.net (holger krekel) Date: Wed, 30 Jun 2004 20:55:34 +0200 Subject: [pypy-dev] utest conversion tool question In-Reply-To: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com> References: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com> Message-ID: <20040630185534.GI16751@solar.trillke> Hey Laura, [Laura Creighton Wed, Jun 30, 2004 at 04:43:25PM +0200] > I am still dizzy and sick, but I am trying to get something done anyhow. I have > this question. ups, didn't know you were ill, but you seem to have fun recovering :-) > If you start with > > self.assertEquals(f(x) + > g(x) == q(x), 'Message to print when the assertion fails') Oh, ^^^^ you mean a comma here, i guess?! > you would like things to come back as > > assert f(x) +\ > g(x) == q(x), 'Message to print when the assertion fails' actually i'd prefer assert f(x) + g(x) == q(x), 'Message to print when the assertion fails' Because i think the output logic should just format it so that it looks nice (e.g. less < 76 characters per line) and retain the correct semantics of the original statement. I wouldn't worry about the original input format, though. If this proves too hard then maybe blame Armin who suggested the 'comma'-try-parsing-withought-understanding-the expression-tricks :-) Regarding your string-parsing question ... > ... > But there is this problem. > > >>> s=''' > ... aaa > ... bbb > ... ccc > ... ''' > >>> s > '\naaa\nbbb\nccc\n' > >>> > >>> assert ''' > ... aaa > ... bbb > ... ccc > ... ''' != s > Traceback (most recent call last): > File "", line 1, in ? > AssertionError > >>> > > thus if I get some code: > > self.assertNotEquals(''' > aaa > bbb > ccc > ''', s) > > I should not be pasting in the backslashes. > > But > > >>> parser.expr(s) > Traceback (most recent call last): > File "", line 1, in ? > File "", line 3 > bbb > ^ > SyntaxError: invalid syntax > >>> > .... suggestions on how to recognise triple-quoted strings? > > Apologies if I miss something obvious, my brain isn't really good for much yet. I think you are mixing the string s with its repr-esentation in source code. When you actually try-to-parse self.assertNotEquals(''' aaa bbb ccc ''', s) then you will at some point pass "'\naaa\nbbb\nccc'" to parser.expr() which will succeed. HTH and happy recovery, Holger From hpk at trillke.net Wed Jun 30 21:05:05 2004 From: hpk at trillke.net (holger krekel) Date: Wed, 30 Jun 2004 21:05:05 +0200 Subject: [pypy-dev] utest conversion tool question In-Reply-To: <20040630183514.GA30220@vicky.ecs.soton.ac.uk> References: <200406301443.i5UEhPd4005104@ratthing-b246.strakt.com> <20040630183514.GA30220@vicky.ecs.soton.ac.uk> Message-ID: <20040630190505.GJ16751@solar.trillke> Hi Armin, [Armin Rigo Wed, Jun 30, 2004 at 07:35:14PM +0100] > self.assertEquals(f(x) + > g(x) == q(x), > 'Message') > > should, intuitively, get translated to... > > assert (f(x) + > g(x) == q(x)), ( > 'Message') Aehem, which kind of intuition are you invoking? I guess intuitive as seen from an algorithm but certainly not nice for a human eye, right? (apart from the fact, that the first '==' probably should be a comma). So i would suggest assert f(x) + g(x) == q(x), 'Message' as the desired output unless this is NP-complete to compute :-) cheers, holger From tinuviel at fluid.sparcs.net Wed Jun 30 14:24:36 2004 From: tinuviel at fluid.sparcs.net (Seo Sanghyeon) Date: Wed, 30 Jun 2004 21:24:36 +0900 Subject: [FW: Re: [pypy-dev] Patches?] Message-ID: <20040630122436.GA28773@fluid.sparcs.net> Oops, replied in private by mistake... ----- Forwarded message from tinuviel ----- To: Ben Young Subject: Re: [pypy-dev] Patches? On Wed, Jun 30, 2004 at 11:08:38AM +0100, Ben Young wrote: > Hi, > > I have been following the pypy-dev mailing list for some time, as well as > maintaining a anon svn checkout of the pypy source and am really excited by > this project (in fact it has inspired me to write my own experimental > language in python along similar lines!). Welcome to PyPy! > I was just wondering whether the > project is considered stable enough to accept patches and/or bug reports from > people who are not directly developers (i.e me!). I have been playing with > getting pypy to run some of my own python programs, and although it seems to > get pretty close there are a couple of issues. PyPy is not exactly stable, but I think patches are welcome any time. > The first is in appspace/operator.py where if you import this in the trivial > object space then is gives errors about modifying a dictionary while > iterating over it. This can be fixed by the following patch > (patch follows) Fixed in r5407, but in a different way. In case you don't read the commit mailing list, here is the detail: http://codespeak.net/pipermail/pypy-svn/2004-June/002572.html In short, "#ugh" part is removed altogether. It was a hack, and it was there to make built-in function never-bound as in CPython. (See the checkin message.) If you don't understand what that means, try this: ==== from operator import add def add2(x,y): return x+y class X: pass X.add = add X.add2 = add2 print X().add(2,2) print X().add2(2,2) ==== CPython doesn't raise exception for X().add, but do for X().add2. That's because built-in function operator.add is never-bound. PyPy before commit does the same. PyPy after commit raise exception for both. > The second is in pprint. If you do > > >>>> import pprint > >>>> pprint.pprint([]) > > you get a massive traceback which I haven't yet quite worked out a fix for. This seems to work in the standard object space though. Regards, ----- End forwarded message -----