A RetroSearch Logo

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

Search Query:

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

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

[Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS [Python-Dev] [Python-checkins] r59947 - in python/trunk:Lib/test/test_structseq.py Misc/NEWS"Martin v. Löwis" martin at v.loewis.de
Tue Jan 15 00:28:27 CET 2008
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 struct_time could still be a proper class, as long as mktime
accepts that as well.

Regards,
Martin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4