holger krekel <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
