[pypy-dev] Re: stuff

[Michael Hudson]

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
>>    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