Inconsistencies in __next__ method for certain types

[abonie]

Hello all,

I am currently working on implementation of next function from __builtin__ module (abonie@e7cff00 it's for my 1st contribution before applying for GSoC).

I have noticed that certain types, like set or int have __next__ method, which is inconsistent with standard CPython implementation. What is worse, set's __next__ raises StopIteration exception (while int's raises TypeError which is still unexpected, but slightly better).
I actually did not manage to pinpoint code responsible for this - I confirmed this behaviour by running sample code in "Batavia testbed" i.e. development server from testserver/ directory (I am new here, so don't know any better way yet). The code looked like this:

a = set([1])  # Substitute objects of different type here
print(a.__next__())

And in this case console output from Batavia is:

Traceback (most recent call last):
  File "/tmp/tmp1wk4vf3w", line 2, in <module>
StopIteration

but it should be an AttributeError.

Looks like a bug to me, but I am only getting familiar with this project for less than a day.
Is it expected behaviour or a known issue?

[freakboy3742]

With very few exceptions, any way you can demonstrate that the public API for CPython differs from Batavia is a bug. In this case, you've definitely found a problem.

Batavia is in a period of rapid development, so it's easy for this sort of inconsistency to drift in. There's been lots of copy-and-paste-and-rename engineering, and that won't always result in completely accurate results.

There is also the possibility that an incorrect implementation has been merged because it passes some superficial test, but would fail a deeper test. For example, the problem you describe with iterating over sets would be consistent with an implementation where the set can operate as it's own iterator - which will work for any simple "iterate over this set" test, but will fail if you start looking closer (as you have).

So yes - this needs to be fixed :-)

[abonie]

All right, thanks for your answer. I don't think I'll have time to get to the bottom of this soon, but for anyone taking on this bug:
So far I established that when Set calls PyObject constructor, unexpectedly StrIterator appears on list of classes that are checked for method resolution order (this happens here, but I have no idea how https://github.com/pybee/batavia/blob/master/batavia/core/types/Object.js#L11).