hpk at trillke.net
Tue Jun 15 16:58:54 CEST 2004
[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
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.
More information about the Pypy-dev