StaticTuple... naming, maintenance, ...

[John Arbash Meinel]

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


...

> I guess we could start checking in and shipping the C files, though
> people have identified that this would cause some considerable churn,
> and perhaps there were other problems.
> 
> I'd be reluctant to add such a high dependency, but if you really want
> it I don't think we should block it.  The dirstate code shows me we
> should bias the dependencies/speed/clarity tripod more towards speed
> and clarity.
> 
>> I'd like to get some feedback, so I have a feel what I need to do to
>> finish this off and get it landed. I think this is a net win, and we
>> just need to decide some of the finer details and balance points.
> 
> Would you like more feedback or a code review?
> 

I just had another serious question. What to do about the pure-python
fallback code?

At the very beginning, I wrote the code so that it was (effectively):

def StaticTuple(*args):
 return args

So you were left with just a simple tuple object. However, Robert
rightly pointed out that it would be nice to have an object that we
could possible add attributes to, and I even added ".intern()" specifically.

However, if we use that layer of abstraction, it is going to *double*
the pure-python memory consumption. Since you know have a GC tuple + a
GC wrapper class (with one member)...

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."

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

iEYEARECAAYFAkrKqssACgkQJdeBCYSNAAN1LQCg0WXMHDM/NWhwOieEcI0SBE/K
JrsAnjbaY9EXJ14evVfpG5u+1GR9qUhI
=g5Zd
-----END PGP SIGNATURE-----