diff options
author | Tim Peters <tim.peters@gmail.com> | 2001-05-05 03:56:37 +0000 |
---|---|---|
committer | Tim Peters <tim.peters@gmail.com> | 2001-05-05 03:56:37 +0000 |
commit | c6ebbea8221776ae35b2fc1c1c7697addabbad91 (patch) | |
tree | 4970e8d18cb948916198570acfbb288247650122 /Misc | |
parent | fe975c3b77c997ed4edc9e2fba259c14ab0410d5 (diff) | |
download | cpython-c6ebbea8221776ae35b2fc1c1c7697addabbad91.tar.gz |
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.
Diffstat (limited to 'Misc')
-rw-r--r-- | Misc/NEWS | 4 |
1 files changed, 2 insertions, 2 deletions
@@ -24,9 +24,9 @@ Core min() reduce() XXX TODO string.join(), unicode.join() - XXX TODO tuple() + tuple() XXX TODO zip() - XXX TODO 'x in y' (!) (?) + XXX TODO 'x in y' What's New in Python 2.1 (final)? ================================= |