Raymond Hettinger wrote:

Here's a couple more if you want to proceed down that path:

1. Have structseq subclass from PyTupleObject so that isinstance(s,
tuple) returns True.  This makes the object usable whenever 
tuples are needed.

2. Add _fields, _asdict, and _replace to match the API in
collections.namedtuple().  The _fields tuple should only include the 
visible positional fields while _asdict() and _replace() should include
all of the fields whether visible or accessible only by 
attribute access.

3. Change the constructor to accept keyword args so that eval(repr(s))
== s works.

NOTE:
I've marked the task as easy but it's not a task for a total newbie.
It's a feasible yet challenging task for somebody who likes to get into
CPython core programming. Basic C knowledge is required!

Here is a patch for #1.  I ran make test, and nothing was broken that
seemed to be my fault, so I assume it's okay.

Yes, it's small, it's my first one here.  I'll get to the other two
tomorrow.

Thanks for the patch.  I removed the whitespace changes and added some
tests to make sure structseq now works with the % formatting operator
and isinstance(t,tuple).

Am getting a sporadic segfault in test_zipimport when running "make
test", so holding-off on applying:

test_zipimport
~/py26/Lib/test/test_zipimport.py:91: ImportWarning: Not importing
directory '/home/rhettinger/py26/Modules/zlib': missing __init__.py
  ["__dummy__"])
make: *** [test] Segmentation fault

I just svn upped (it updated zipimport) and applied your patch, and
'./python Lib/test/regrtest.py test_zipimport.py' says it's okay, so I
would go ahead and commit it.

Run, "make test" a few times to make sure it doesn't bomb.

The problem may be due to needing a deferred_type instead of assigning
&PyTupleObject directly.  Will look it more later.

It worked fine on a fresh check-out.  Committed in revision 59967.

Is there something else to be done for this to be closed?

All three items are still open.  The second one is the easiest.

See also issue 2308

Jack, do you have any interest in putting this one over the goal line?

In Py3.x, this fails:
    "%s.%s.%s-%s-%s" % sys.version_info

The reason is that PyUnicode_Format() expects a real tuple, not a tuple
lookalike.  The fix is to either have structseq inherit from tuple or to
modify PyUnicode_Format() to handle structseq:

   if (PyCheck_StructSeq(args)) {
      newargs = PyTuple_FromSequence(args);
      if (newargs == NULL)
          return NULL;
      result = PyUncode_Format(format, newargs);
      Py_DECREF(newargs);
      return result;
   }

Raymond Hettinger wrote:
> Raymond Hettinger <rhettinger@users.sourceforge.net> added the comment:
> 
> In Py3.x, this fails:
>     "%s.%s.%s-%s-%s" % sys.version_info
> 
> The reason is that PyUnicode_Format() expects a real tuple, not a tuple
> lookalike.  The fix is to either have structseq inherit from tuple or to
> modify PyUnicode_Format() to handle structseq:
> 
>    if (PyCheck_StructSeq(args)) {
>       newargs = PyTuple_FromSequence(args);
>       if (newargs == NULL)
>           return NULL;
>       result = PyUncode_Format(format, newargs);
>       Py_DECREF(newargs);
>       return result;
>    }

-1

The special-casing of tuples vs. non-tuples for % is already
bad enough. Adding structseq as another special case doesn't
make that any better.

What's so hard about writing

"%s.%s.%s-%s-%s" % tuple(sys.version_info)

anyway ?

ISTM that structseq should have been a tuple subclass anyway.  Isn't it
advertised as some sort of "tuple with attribute access"?

For those who missed it, the patch that was committed in r59967 was
quickly reverted in r59970 with the comment:

"Temporarily revert 59967 until GC can be added."

Raymond, can you please explain what was missing from the patch?

See also issue 8413, which would be addressed by this change.

I agree that the priority is higher now that we have a demonstrable regression.

Getting structseq to subclass from tuple will take some effort (tuples have many methods that would need to be overriden).

structseq now does subclass tuple, so if there's any interest in adding namedtuple APIs, now it should be easier.

Would whatever remains of this be deferred by the PEP3003 moratorium?

I don't think it would be covered by the moratorium, since it's not a language change. The change to make structseq derive from tuple was not subject to the moratorium, for example.

This is definitely not covered by the language moratorium.  Guido has requested this change and it needs to go forward.

Issue5907 would benefit of this change.
Unfortunately, structseq constructors already have keyword arguments; they are equivalent to "def __new__(cls, sequence, dict=NULL)".
OTOH these keywords arguments are not documented anywhere.

I suggest to change the constructor to something equivalent to:
"def __new__(cls, sequence=NULL, dict=NULL, *, field1=NULL,  field2=NULL)"

Also see issue 11698

Hasn't this been fixed in the following changeset?

changeset:   43509:384f73a104e9
user:        Benjamin Peterson <benjamin@python.org>
date:        Wed Jul 07 20:54:01 2010 +0000
summary:     make struct sequences subclass tuple; kill lots of code

> Hasn't this been fixed in the following changeset?

It was a major step forward.  Now there needs to be work on other namedtuple methods and whatnot.