StaticTuple... naming, maintenance, ...

[John Arbash Meinel]

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


...

>>   Compare: "key = (file_id, revision_id)"
>>   versus:  "key = StaticTuple(file_id, revision_id)"
>>   or even: "key = StaticTuple((file_id, revision_id))"
>>
>>   I think lowercase is reasonable, though I wonder about
>>            "key = stuple(file_id, revision_id)"
> 
> Well, you could always do "... import StaticTuple as stuple".  I'd be
> inclined to make the canonical name fairly formal.

k

> 
>> 2) Constructor args:
>>   "tuple(X)" takes a sequence X, however if you want to create a
>>   3-tuple you have the (a, b, c) short form
>>
>>   As such, I was planning on making "StaticTuple(*args)", so that you
>>   can just change:
>>     foo = (a, b, c)
>>   into:
>>     foo = StaticTuple(a, b, c)
>>
> 
> Sounds good
> 
>>   I would probably have a separate "StaticTuple.from_sequence()" for
>>   the other form. You certainly can do StaticTuple(*t), however the
>>   main loss is that "tuple(tuple(t)) is t", while
>>   StaticTuple(*st) would have to be a new object.
> 
> Right, because *st would presumably turn it into a plain tuple.
> 
> But you could have StaticTuple(st) just return st, couldn't you?

You could, but then how do you represent:
 ((1,2,),)

Consider a file_key parents list with only one parent:

{(file_id,rev_id): ((file_id,rev_id2),)}

We need to both nest these things, and have them hold a single entry.


...

>>    The difficulty is that would be a hard jump to go from Python 0.8 or
>>    so (doesn't even support +=) to Cython 0.11 (it is in Karmic, but
>>    Jaunty only have Cython 0.10).
>>
>>    I would *really* like to switch to Cython 0.11+, as I have specific
>>    benefits. One could argue that we could try to be compatible, and
>>    people can compile using Pyrex, and just wouldn't get the memory and
>>    speed improvement of avoiding the GC...
>>
>>    I'm also using stuff like 'cpdef' and 'inline', but I can work
>>    around those things easily enough. I can't hack the 'HAVE_GC' flag
>>    easily.
> 
> 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.

If we start checking in the C files, we need a post-processor that runs
between:

  cython foo_pyx.pyx => foo_pyx.c
  postprocess foo_pyx.c => foo_pyx.c
  gcc foo_pyx.c => foo_pyx.so

We can certainly do it, and it doesn't change a lot about the dependency
change (*.c will be newer than *.pyx unless it needs to be built, etc).


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

So we could make an exception for this one file, and have me go ahead
and do a minimal post-processing, and see how it goes...

It would be a bit of a shame to have the feature blocked on it...

> 
>> 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?
> 

For now, I'm looking primarily for guidance on the questions posited.
Tomorrow I can respond, and probably have something up for review.

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

iEYEARECAAYFAkrKkwMACgkQJdeBCYSNAAPptwCeJmk485XcSa+pNE5lTUqtBK06
2/EAoKiRIyFjRwzata5iS+kHZClaYGFl
=htP1
-----END PGP SIGNATURE-----