Unexpected errors in calling the __iter__ method are no longer
masked by TypeError in the "in" operator and functions
operator.contains(), operator.indexOf() and operator.countOf().
(cherry picked from commit cafe1b6e9d)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
- Issue #25958: Support "anti-registration" of special methods from
various ABCs, like __hash__, __iter__ or __len__. All these (and
several more) can be set to None in an implementation class and the
behavior will be as if the method is not defined at all.
(Previously, this mechanism existed only for __hash__, to make
mutable classes unhashable.) Code contributed by Andrew Barnert and
Ivan Levkivskyi.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r82165 | benjamin.peterson | 2010-06-22 15:26:20 -0500 (Tue, 22 Jun 2010) | 1 line
must force gc here
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r68560 | amaury.forgeotdarc | 2009-01-13 00:36:55 +0100 (mar., 13 janv. 2009) | 6 lines
#3720: Interpreter crashes when an evil iterator removes its own next function.
Now the slot is filled with a function that always raises.
Will not backport: extensions compiled with 2.6.x would not run on 2.6.0.
........
svn+ssh://pythondev@svn.python.org/python/branches/p3yk
........
r56127 | georg.brandl | 2007-06-30 09:32:49 +0200 (Sat, 30 Jun 2007) | 2 lines
Fix a place where floor division would be in order.
........
r56135 | guido.van.rossum | 2007-07-01 06:13:54 +0200 (Sun, 01 Jul 2007) | 28 lines
Make map() and filter() identical to itertools.imap() and .ifilter(),
respectively.
I fixed two bootstrap issues, due to the dynamic import of itertools:
1. Starting python requires that map() and filter() are not used until
site.py has added build/lib.<arch> to sys.path.
2. Building python requires that setup.py and distutils and everything
they use is free of map() and filter() calls.
Beyond this, I only fixed the tests in test_builtin.py.
Others, please help fixing the remaining tests that are now broken!
The fixes are usually simple:
a. map(None, X) -> list(X)
b. map(F, X) -> list(map(F, X))
c. map(lambda x: F(x), X) -> [F(x) for x in X]
d. filter(F, X) -> list(filter(F, X))
e. filter(lambda x: P(x), X) -> [x for x in X if P(x)]
Someone, please also contribute a fixer for 2to3 to do this.
It can leave map()/filter() calls alone that are already
inside a list() or sorted() call or for-loop.
Only in rare cases have I seen code that depends on map() of lists
of different lengths going to the end of the longest, or on filter()
of a string or tuple returning an object of the same type; these
will need more thought to fix.
........
r56136 | guido.van.rossum | 2007-07-01 06:22:01 +0200 (Sun, 01 Jul 2007) | 3 lines
Make it so that test_decimal fails instead of hangs, to help automated
test runners.
........
r56139 | georg.brandl | 2007-07-01 18:20:58 +0200 (Sun, 01 Jul 2007) | 2 lines
Fix a few test cases after the map->imap change.
........
r56142 | neal.norwitz | 2007-07-02 06:38:12 +0200 (Mon, 02 Jul 2007) | 1 line
Get a bunch more tests passing after converting map/filter to return iterators.
........
r56147 | guido.van.rossum | 2007-07-02 15:32:02 +0200 (Mon, 02 Jul 2007) | 4 lines
Fix the remaining failing unit tests (at least on OSX).
Also tweaked urllib2 so it doesn't raise socket.gaierror when
all network interfaces are turned off.
........
that already is a string or the existence of the str class
is checked or a check is done for str twice. These all stem
from the initial unicode->str replacement.
svn+ssh://pythondev@svn.python.org/python/branches/p3yk
........
r55077 | guido.van.rossum | 2007-05-02 11:54:37 -0700 (Wed, 02 May 2007) | 2 lines
Use the new print syntax, at least.
........
r55142 | fred.drake | 2007-05-04 21:27:30 -0700 (Fri, 04 May 2007) | 1 line
remove old cruftiness
........
r55143 | fred.drake | 2007-05-04 21:52:16 -0700 (Fri, 04 May 2007) | 1 line
make this work with the new Python
........
r55162 | neal.norwitz | 2007-05-06 22:29:18 -0700 (Sun, 06 May 2007) | 1 line
Get asdl code gen working with Python 2.3. Should continue to work with 3.0
........
r55164 | neal.norwitz | 2007-05-07 00:00:38 -0700 (Mon, 07 May 2007) | 1 line
Verify checkins to p3yk (sic) branch go to 3000 list.
........
r55166 | neal.norwitz | 2007-05-07 00:12:35 -0700 (Mon, 07 May 2007) | 1 line
Fix this test so it runs again by importing warnings_test properly.
........
r55167 | neal.norwitz | 2007-05-07 01:03:22 -0700 (Mon, 07 May 2007) | 8 lines
So long xrange. range() now supports values that are outside
-sys.maxint to sys.maxint. floats raise a TypeError.
This has been sitting for a long time. It probably has some problems and
needs cleanup. Objects/rangeobject.c now uses 4-space indents since
it is almost completely new.
........
r55171 | guido.van.rossum | 2007-05-07 10:21:26 -0700 (Mon, 07 May 2007) | 4 lines
Fix two tests that were previously depending on significant spaces
at the end of a line (and before that on Python 2.x print behavior
that has no exact equivalent in 3.0).
........
and .keys(), .items(), .values() return dict views.
The dict views aren't fully functional yet; in particular, they can't
be compared to sets yet. but they are useful as "iterator wells".
There are still 27 failing unit tests; I expect that many of these
have fairly trivial fixes, but there are so many, I could use help.
I mea, *really* equal -- for now, the implementation just imports
itertools. :-)
The only other changes necessary were various unit tests that were
assuming zip() returns a real list. No "real" code made this assumption.
in the stdlib and changed each of them to use "open" instead. At this
time there are no other known occurrences that can be safely changed (in
Lib and all subdirectories thereof).
imports e.g. test_support must do so using an absolute package name
such as "import test.test_support" or "from test import test_support".
This also updates the README in Lib/test, and gets rid of the
duplicate data dirctory in Lib/test/data (replaced by
Lib/email/test/data).
Now Tim and Jack can have at it. :)
iterable object. I'm not sure how that got overlooked before!
Got rid of the internal _PySequence_IterContains, introduced a new
internal _PySequence_IterSearch, and rewrote all the iteration-based
"count of", "index of", and "is the object in it or not?" routines to
just call the new function. I suppose it's slower this way, but the
code duplication was getting depressing.
- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.
NEEDS DOC CHANGES.
More AttributeErrors transmuted into TypeErrors, in test_b2.py, and,
again, this strikes me as a good thing.
This checkin completes the iterator generalization work that obviously
needed to be done. Can anyone think of others that should be changed?
safely together and don't duplicate logic (the common logic was factored
out into new private API function _PySequence_IterContains()).
Visible change:
some_complex_number in some_instance
no longer blows up if some_instance has __getitem__ but neither
__contains__ nor __iter__. test_iter changed to ensure that remains true.
NEEDS DOC CHANGES
A few more AttributeErrors turned into TypeErrors, but in test_contains
this time.
The full story for instance objects is pretty much unexplainable, because
instance_contains() tries its own flavor of iteration-based containment
testing first, and PySequence_Contains doesn't get a chance at it unless
instance_contains() blows up. A consequence is that
some_complex_number in some_instance
dies with a TypeError unless some_instance.__class__ defines __iter__ but
does not define __getitem__.
to string.join(), so that when the latter figures out in midstream that
it really needs unicode.join() instead, unicode.join() can actually get
all the sequence elements (i.e., there's no guarantee that the sequence
passed to string.join() can be iterated over *again* by unicode.join(),
so string.join() must not pass on the original sequence object anymore).
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.
Miss Islington (bot)
Serhiy Storchaka
Guido van Rossum
Ezio Melotti
Kristján Valur Jónsson
Benjamin Peterson
Amaury Forgeot d'Arc
Raymond Hettinger
Collin Winter
Guido van Rossum
Walter Dörwald
Georg Brandl
Brett Cannon
Jack Diederich
Alex Martelli
Tim Peters
Barry Warsaw
Fred Drake
Martin v. Löwis