[pypy-dev] Re: stuff
mwh at python.net
Tue Jun 15 17:38:56 CEST 2004
holger krekel <hpk at trillke.net> 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
> 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.
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
More information about the Pypy-dev