]> granicus.if.org Git - python/commit
Generalize tuple() to work nicely with iterators.
authorTim Peters <tim.peters@gmail.com>
Sat, 5 May 2001 03:56:37 +0000 (03:56 +0000)
committerTim Peters <tim.peters@gmail.com>
Sat, 5 May 2001 03:56:37 +0000 (03:56 +0000)
commit6912d4ddf0504a3d5611ddd12cbde3354bd48279
treeaf9162f00d5169fc8e9c13c0046d61051c2463ed
parentf4848dac41689d1f2f8bd224bd935beae9b8df86
Generalize tuple() to work nicely with iterators.
NEEDS DOC CHANGES.
This one surprised me!  While I expected tuple() to be a no-brainer, turns
out it's actually dripping with consequences:
1. It will *allow* the popular PySequence_Fast() to work with any iterable
   object (code for that not yet checked in, but should be trivial).
2. It caused two std tests to fail.  This because some places used
   PyTuple_Sequence() (the C spelling of tuple()) as an indirect way to test
   whether something *is* a sequence.  But tuple() code only looked for the
   existence of sq->item to determine that, and e.g. an instance passed
   that test whether or not it supported the other operations tuple()
   needed (e.g., __len__).  So some things the tests *expected* to fail
   with an AttributeError now fail with a TypeError instead.  This looks
   like an improvement to me; e.g., test_coercion used to produce 559
   TypeErrors and 2 AttributeErrors, and now they're all TypeErrors.  The
   error details are more informative too, because the places calling this
   were *looking* for TypeErrors in order to replace the generic tuple()
   "not a sequence" msg with their own more specific text, and
   AttributeErrors snuck by that.
Include/abstract.h
Lib/test/output/test_coercion
Lib/test/test_extcall.py
Lib/test/test_iter.py
Misc/NEWS
Objects/abstract.c