Bug 1294130 - pymongo.cursor.Cursor.__next__ is being replaced with the next builtin instead of def __next__()
Summary: pymongo.cursor.Cursor.__next__ is being replaced with the next builtin instea...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-pymongo
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Randy Barlow
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-25 06:24 UTC by Randy Barlow
Modified: 2016-01-18 21:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-18 21:03:28 UTC
Type: Bug
Embargoed:


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

Description Randy Barlow 2015-12-25 06:24:26 UTC
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
 985 
 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:

https://github.com/mongodb/mongo-python-driver/blob/f3931c1e19707eec0afa1f58d2096bd2c1ed2732/pymongo/cursor.py#L972-L986

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
python3-pymongo-3.0.3-2.fc24.x86_64


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
    self._populate_cache()
  File "/usr/lib/python3.5/site-packages/mongoengine/queryset/queryset.py", line 92, in _populate_cache
    self._result_cache.append(next(self))
  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 
yo
sup

Comment 1 Randy Barlow 2015-12-25 06:25:05 UTC
Created attachment 1109336 [details]
mongoengine_test.py

Comment 2 Randy Barlow 2015-12-26 01:19:52 UTC
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 16:29:33 UTC
The upstream release notes explicitly state not to use 2to3 with pymongo >= 3:

https://api.mongodb.org/python/current/changelog.html#changes-in-version-3-0

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 18:24:12 UTC
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 16:44:25 UTC
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.