Commit Graph

4 Commits

Author SHA1 Message Date
Tim Peters 6912d4ddf0 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.
2001-05-05 03:56:37 +00:00
Neil Schemenauer 623116a870 Sequence repeat works now for in-place multiply with an integer type
as the left operand.  I don't know if this is a feature or a bug.
2001-01-04 01:36:25 +00:00
Neil Schemenauer 38796d07a5 Use numbers that can be accurately represented on binary machines. I hope
this works on all platforms.
2001-01-03 01:52:11 +00:00
Neil Schemenauer fd288c7cd5 Add more tests for compare and coercion in preparation for the coercion
overhaul.  Closes SF patch #102878.
2001-01-02 16:30:31 +00:00