Bug 1294130 - pymongo.cursor.Cursor.__next__ is being replaced with the next builtin instead of def __next__()
pymongo.cursor.Cursor.__next__ is being replaced with the next builtin instea...
Product: Fedora
Classification: Fedora
Component: python-pymongo (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Randy Barlow
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-12-25 01:24 EST by Randy Barlow
Modified: 2016-01-18 16:03 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-18 16:03:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mongoengine_test.py (230 bytes, text/plain)
2015-12-25 01:25 EST, Randy Barlow
no flags Details

  None (edit)
Description Randy Barlow 2015-12-25 01:24:26 EST
Description of problem:
The following code appears in /usr/lib64/python3.5/site-packages/pymongo/cursor.py:

 972     def __next__(self):
 973         """Advance the cursor."""
 974         if self.__empty:
 975             raise StopIteration
 976         _db = self.__collection.database
 977         if len(self.__data) or self._refresh():
 978             if self.__manipulate:
 979                 return _db._fix_outgoing(self.__data.popleft(),
 980                                          self.__collection)
 981             else:
 982                 return self.__data.popleft()
 983         else:
 984             raise StopIteration
 986     __next__ = next

That last line replaces the __next__ function with the Python next() builtin, which causes the Cursor not to be iterable. Strangely, the upstream source code that the current Rawhide release is based on does not contain this error:


This is very severe for Python 3 users, but does not seem to affect Python 2 users.

Version-Release number of selected component (if applicable):
$ rpm -q python3-pymongo

How reproducible:
Every time

Steps to Reproduce:
1. Download the attached reproducer, which uses python3-mongoengine.
2. $ sudo dnf install python3-mongoengine
3. $ python3 mongoengine_test.py

Actual results:
[rbarlow@boole ~]$ python3 mongoengine_test.py 
Traceback (most recent call last):
  File "mongoengine_test.py", line 15, in <module>
    for u in User.objects:
  File "/usr/lib/python3.5/site-packages/mongoengine/queryset/queryset.py", line 80, in _iter_results
  File "/usr/lib/python3.5/site-packages/mongoengine/queryset/queryset.py", line 92, in _populate_cache
  File "/usr/lib/python3.5/site-packages/mongoengine/queryset/base.py", line 1407, in __next__
    raw_doc = next(self._cursor)
TypeError: next expected at least 1 arguments, got 0

Expected results:
It should look like the output given by running the same script with python2:

[rbarlow@boole ~]$ python2 mongoengine_test.py 
Comment 1 Randy Barlow 2015-12-25 01:25 EST
Created attachment 1109336 [details]
Comment 2 Randy Barlow 2015-12-25 20:19:52 EST
I performed a test, and I believe it is the 2to3 utility that is making this change. The upstream github page states that pymongo supports Python 2.6 and 2.7, and Pythons 3.2-3.5. Their setup.py does not seem to use 2to3. I would interpret that to mean that 2to3 is not needed with current versions of pymongo, but I am not sure.

Alternatively, it may be possible to exclude the fixer that is renaming next() to __next__() so that this problem goes away.

I recommend investigating whether 2to3 is really needed any longer. If it is not, it would be beneficial to drop it from the spec file.
Comment 3 Randy Barlow 2016-01-14 11:29:33 EST
The upstream release notes explicitly state not to use 2to3 with pymongo >= 3:


This is certainly the issue - please fix this as pymongo does not work with Python 3 and Python 3 is the default Python implementation for Fedora >= 23.
Comment 4 Fedora Admin XMLRPC Client 2016-01-14 13:24:12 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Randy Barlow 2016-01-18 11:44:25 EST
I believe this fix will be straightfoward, as dropping just the 2to3 line makes a package that works in Python 2 and Python 3 with the test I attached earlier.

Note You need to log in before you can comment on or make changes to this bug.