[pypy-dev] stdobjspace summary?

Christian Tismer tismer at tismer.com
Sat Mar 1 05:59:38 CET 2003


Armin Rigo wrote:
> Hello everybody,
> 
> As I won't read my mail during the whole next week I thought it might be
> helpful if I attempted some kind of summary. It collects numerous ideas posted
> here (recently or not) and a bit of personal feelings. I hope it might help in
> getting some distance over what we are actually trying to do with our
> "standard object space". I am afraid it is all very vague, but should be kept
> in mind before we actually design something new there.

[snipped all the goodies]

Thanks for the nice summary. I see that you might have
different opinions, but you accept that there is the
possibility to allow different opinions to coexist,
since we don't target to the one-size-fits-all concept,
that CPython is restricted to by nature.

I think this is a wise decision, since this allows us
to continue without having to fight about peanuts issues:
Assuming that I insist on naked memory arrays, neglecting
any built-in array operations, I can build a worthwile
list implementation. At the same time, you may prefer
to assume more builtin flexibility and implement arrays
in Java-style, either on top of my primitive assembly-like
layer with ease, or just by ignoring it. Both ways are
OK for me. I would just like to write my implementation
now, in the way I think about it, and I'm open to either
wrap it later on top, or to modify it for "the new standard"
or whatever. I just don't think that this will change the
"meat of the implementation", which is not just wrappers
around builtin lists, but that implements hairy stuff like
sorting, dynamic allocation size decisions, and more.

Well, because you are not available next week, please let
me ask some questions, in order to avoid too much diversification
and less later work to get towards the yet not well-defined target:

Assuming I would implement a tuple/list type, what would you
prefer:
An implementation that uses lists just to denotate a malloc'ed
piece of memory, therefore explicitly maintaining actlen and
maxlen, or more of the notation of a Java array? (Which I guess)

Which are the allowed basic operations assumed to be available?

If there were two different implementations, one in terms of
plain memory chunks, and one in terms of Java arrays, how
would they be split? Is there one interface file in std, which
configures itself by some global options and some local include,
or would there be a std_c and a java folder?

As Stephan pointed out in private emails, he actually is in favor
of not doing a long implementation at all, but to link against
an external library. This is personal taste which we should
provide space for. Where do you think this space should live?
And if I pefer to do "real longs", since I'm the earth-bound,
hack-all-or-nothing guy, where should I put my stuff?
Should I create more specific folder names?
Do the STD objects generally turn themselves into just interfaces,
which redirect to something else by some means of config files?

Assuming that I'm going to implement some basic string type,
to you prefer to have this done using builtin Python strings?
Of course, I'd use them for constants, like the C strings,
but then, when I implement them as basic types, I'm thinking
to build them either upon array.array("c","abc") (less likely,
since array is not favored by Guido, and seems to not support
unicode), or by some restricted list class (ouch!), again.
This list class would be meant as a plain memory interface,
allowing no list-level operations like "+", len, append or such,
just creation, indexing and element assignment, and the
implementation would pretty much resemble the current C imple-
mentation.
So the underlying primitive list would be restricted to able to
hold single chars and None, only. This is, as stated in earlier,
less coherent emails, just a way to express what the primitive
type *cannot* do, in order to let the restricted base list object
be error-checked interpreted by CPython, *and* be an easy
target for a simple compiler to C.
The W_Stringobject class would take care of everything a string
can do, by providing every string function that CPython has as well.

If I implement things this way, I think it will be more than easy to
generate C code, even for a simple mind like mine. If you are uneasy
with my way to tackle this, I have no problems if somebody rewrites
the stuff in slightly higher level style, or if (s)he wraps it
up, claiming "this is the Java level implementation". No problem.
But allowing for this allows me to write what I want to write,
right now.
What I'm just asking for is just how I should put it where,
in which directory, with which file naming conventions.
I think it's more efficient to just let me keep going in
some way, than to let me get stuck in some general interface/
/principle discussion, which is neither my point nor my strength.

There is another issue concerning builtins and similar stuff,
where we also still have no coherent interface for, and I'm
going to propose a simple-minded approach, just to get people
like me started. Will write that up in another thread.

thanks for your patience with the ancient hacker -- chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/




More information about the Pypy-dev mailing list