[pypy-dev] Re: Base Object library (was: stdobjspace status)
stephan.diehl at gmx.net
Thu Feb 27 18:42:00 CET 2003
On Thursday 27 February 2003 18:01, you wrote:
> Hello Stephan,
> On Thu, Feb 27, 2003 at 05:23:44PM +0100, Stephan Diehl wrote:
> > About object instantiation:
> > Where excatly is the textual representation of a python object turned
> > into an object? Is it done by the parser? (for example "12345L" -->
> > 12345L)
> Damn. I don't know.
> If we don't include any 'long' type among our allowed
> RPython types (and we probably don't), then we will have to rethink the way
> code objects are currently completely put into interpreter-space level.
> This cannot work if this code object contains constants of unknown types!
Maybe, then RPython was not a very good idea in the first place.
> So it seems that even code objects must be object-space dependent. They
> would be compiled by the application-level 'compiler' package inside of a
> given object space, and not be 'extractible' from there. The interpreter
> would only unwrap the bytecode string, but not the tuple of constants.
> If on the other hand we would prefer completely portable code objects, then
> they must contain "portable constant literals", including longs, and wrap()
> must support at least these constants. This could be nice, too, because we
> could then have object-space-independent bytecode repositories (like .pyc
> files). But then we must include in RPython the notion of longs -- at
> least their existence, not necessarily any specific operation on them. The
> same about complex numbers.
Would it help if the bytecode just holds the string representation of an
object? I guess the lexer gives down the string plus type information. maybe
somthing like ('long','12345L'). If this were taken as it is into the
bytecode, the interpreter then could run the instantiation on the fly.
But then, the question is, if the ObjSpaces we are talking about could live
in Application Space? The interpreter just requires some Object types to be
present in order to function.
In order to be used as an internal type, the XXXObjects just have to comply
to some interface and know how to create oneselfs from a string (and give the
compiler some regexp so it can be known).
(Hmm, this is probably a little bit too off target)
Anyway, this stuff must not be decided now.
> Tough choice.
> pypy-dev at codespeak.net
More information about the Pypy-dev