On Jan 13, 2008 11:22 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
