RetroSearch Browse

Mon Jan 14 16:37:45 CET 2008 · https://mail.python.org/pipermail/python-dev/2008-January/076163.html

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/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-January/076163.html below:

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