[Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS (original) (raw)
Guido van Rossum guido at python.org
Tue Jan 15 00:37:13 CET 2008
- Previous message: [Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
- Next message: [Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
A use case for slicing was just found in zipfile.py:
date = "%d-%02d-%02d %02d:%02d:%02d" % zinfo.date_time[:6]
On Jan 14, 2008 3:28 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
Guido van Rossum wrote: > On Jan 14, 2008 2:19 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote: >>> Correct. We don't need item access anymore. However the struct seq >>> should still be slice-able for functions like time.mktime(). >> Can you please explain that? What application do you have in mind? > > Well, mktime() assumes its argument to be a tuple, and there are > plenty of places that either emulate its API (like calendar.timegm()) > or provide a tuple for it. I wouldn't want to lose the ability to > manually construct a tuple to go into mktime() and friends.
But what about the slicing? AFAICT, mktime doesn't support "short" tuples. mktime could continue to support tuples (including manually created ones), yet structtime could still be a proper class, as long as mktime accepts that as well. Regards, Martin
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
- Next message: [Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]