structseq and keywords?

[Nick Mathewson]

As the original author of the structseq patch, I should respond.

In article <ulmcwsr38.fsf at python.net>, Michael Hudson wrote:
> quinn at vomit.ugcs.caltech.edu (Quinn Dunkan) writes:
 [...]
> In the current implementation, you're not really expected to create
> structseq objects.  Why would you?

I agree with this.  One of the explicit design decisions was that
since it's so easy to create a lookalike class in Python, there's not
a lot of reason to expose structseq as a metatype.

In the case of its uses today (localtime, stat, statvfs), there didn't
seem to be a lot of reason to want to create these objects yourself.

BTW, people should not (IMO) be creating new structseq-based
interfaces at all.  Here's why: The structseq interface is meant to be
used in cases where legacy code expects a tuple, but where an
attribute-based interface would be more sensible.  If you're creating
a new interface, and you want an attribute-based interface, don't use
a structseq in the first place.

>> I've been meaning to give python access to structseqs, since I think
>> it would be useful for python as well as C code.
> 
> Hmm.  I think they're a bit specialized for that.  You could probably
> whip up something nearly equivalent...

 [...nice Python equivalent of structseq elided...]

> Doesn't do everything structseqs do, but that's mostly a matter of
> typing.

Watch out, though: If you're supporting legacy code that expects a
tuple, you'd better support _all_ the tuple operations out there:
somplace, there is going to be an eccentric who's been using slices
and concatenations to manipulate the things.  

(And if you're _not_ supporting legacy code that expects a
tuple... don't use a structseq-ish class at all.)

If-a-camel-is-a-horse-designed-by-committee-then-is-a-llama-
   a-horse-designed-for-backward-compatibility-with-a-sheep?-ly Y'rs,
-- 
 Nick Mathewson    <Q nick Q m at alum dot mit dot edu>
                      Remove Q's to respond.  No spam.