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