StaticTuple... naming, maintenance, ...

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...
>> Should I make ".intern()" a module level function? Or just live with the
>> statement "we don't make special treatment for pure python code, if you
>> want low memory and speed, compile the extensions."
> 
> The Python code ought to emphasize clarity.  That said, we do want it
> to be usable, and doubling the memory use would be a heavy price.  So
> I think putting the intern code into a function that can be called,
> passing such an object, would be a reasonable price.  Up to you.
> 


So I thought about it some more, and it may not have to be that way.
Specifically, the python btree parsing code could still use tuples. The
main issue is if we want to say "always the 'statictuple' type" comes
out of the parser. For example, in CHKMap I had to change a lot of lines
from:

 for node in self._items:
    if type(node) is tuple:
       keys.add(node)

to

  for node in self._items:
     if type(node) in (tuple, StaticTuple):
       keys.add(node)
...

The alternative is to do:

     if type(node) in (LeafNode, InternalNode):
       ...
     else:
       keys.add(node)

And I think that amounts to ~the same runtime overhead.

In general, I'm not sure that '.intern' will be particularly useful to
code outside of a C extension that we already have for parsing. The
index layer and the CHK layer deal in keys, but we already have them
with extensions. Everything else isn't going to be *generate* 100k of
these objects.

Anyway, I'll think about it some more.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrK1R0ACgkQJdeBCYSNAAMndACgnJNWO+EnPwW8O7kDwB6uL7Vg
76kAn3ht6hBK4ShK+9mDYGT0vHcwbe4D
=ms2s
-----END PGP SIGNATURE-----