[Stackless] Stackless 2.3 CVS on OS X, test failures
tismer at stackless.com
Sun Jan 25 18:12:20 CET 2004
Bob Ippolito wrote:
> On Jan 25, 2004, at 7:06 AM, Christian Tismer wrote:
[pickling more iterator types]
>> Adding this pickle support should not be too hard and quite
>> straight forward. Have a look at prickelpit.c where almost
>> all pickling code lives. There is some support that allows
>> to patch the type objects and method tables without patching
>> their source code at all, which I prefer, to keep the number of
>> patched files as small as possible. (I'm trying to reduce these,
>> further). I guess it would be possible to create a few generic
>> functions for all iterators and control them via format strings,
>> since they are very similar?
> They are not similar, with the exception of listiterator and
> tupleiterator. This implementation is not well tested (but the code
> doesn't do much, so I can't imagine what I got wrong).
First of all, many thanks!
I guess you want to check-in yourself, since you have
cvs write access now?
While you are at it, you might want to remove the code for
__safe_for_unpickling__ as well. (2.3 only, of course).
> I made a few decisions that I'm not sure about, but they are performance
> not functionality or correctness related (I think).
I think it is just great to have them at all, in the first
place. We can see whether some need to be enhanced.
> * dictionary-iterator makes a list copy of the rest of the iteration
> because it's not possible to determine if it was iter(keys|values|items)
> b/c they're pointers to static functions with no symbols.
That doesn't matter. If we want, we can add some initialization
code (lazy, I guess), that just creates such an iterator once
and records the function pointers in a static table.
When pickling, we can encode that as 0, 1, 2
or "keys", "values", "items".
> When reduced,
> it looks like a PySeqIter_Type starting at 0 with a list.
That's most probably sufficient in most cases, although we know
that there can be misuses. Well, since there is no introspection,
we also don't need to store the dictionary.
But some situations might be weird, for instance, if they iterate
over a module dict, which is never to be stored at all.
Hmm. That's a really weird case where I don't know what to do.
> * listiterator makes a slice of the list. When reduced, it looks like
> a PySeqIter_Type starting at 0 with a list.
> * tupleiterator makes a slice of the tuple. When reduced, it looks
> like a PySeqIter_Type starting at 0 with a tuple.
Why the above? I don't seee nay technical reason, but I guess
you want to save the space?
> * I had a hard time getting at some of the types (they are private..)
> so I had to create the host object, then make it iter, and snag the type
> off of them.
Instead of patching around to make these types public,
I keep identical copies of the private declarations.
I think it would mae sense to have some script
in some future that checks such replicated type declarations
for being correct. I thought of something similar to check
the code duplications in nonrecursive.c as well.
Did it by hand, again. later :-)
ciao - chris
Christian Tismer :^) <mailto:tismer at stackless.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 mobile +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/
Stackless mailing list
Stackless at stackless.com
More information about the Stackless