[Python-checkins] [Python-Dev] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS

Guido van Rossum guido at python.org
Mon Jan 14 16:37:45 CET 2008


On Jan 13, 2008 11:22 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > Hmm, is that really necessary? structseq has been in use for quite a
> > while and this need hasn't come up -- it's been designed to be quite
> > compatible with tuple *except* for isinstance checks, and that has
> > worked well.
>
> In addition, I would like to suggest that the current structseq usage
> is changed to regular classes (perhaps with slots) in Python 3.
> structseq was a compatibility mechanism for existing code that assumes
> the things returned are tuples, when they are really objects with named
> fields.
>
> So for struct stat and struct tm in particular, I think the indexed
> access should be removed in Python 3. Whether then structseq needs
> to be preserved at all, I don't know.

There seems to be a use case for it still, otherwise
collections.namedtuple wouldn't be added to 2.6, right? I agree that
it's time to clean up the tuple-ness of the stat and tm structures
(especially since they both may have "hidden" fields that are not
accessible via the tuple structure). And I see no need for the new
sys.flags object to be a tuple at all.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-checkins mailing list