Adding MAL's comment about next() vs. __next__().
This commit is contained in:
parent
701fba5cdb
commit
bc657d06b6
|
@ -102,7 +102,13 @@ C API Specification
|
|||
special name. On the other hand, this would suggest that there
|
||||
should also be a primitive operation next(x) that would call
|
||||
x.__next__(), and this just looks like adding complexity without
|
||||
benefit. So I think it's better to stick with next().
|
||||
benefit. So I think it's better to stick with next(). On the
|
||||
other hand, Marc-Andre Lemburg points out: "Even though .next()
|
||||
reads better, I think that we should stick to the convention that
|
||||
interpreter APIs use the __xxx__ naming scheme. Otherwise, people
|
||||
will have a hard time differentiating between user-level protocols
|
||||
and interpreter-level ones. AFAIK, .next() would be the first
|
||||
low-level API not using this convention."
|
||||
|
||||
|
||||
Python API Specification
|
||||
|
|
Loading…
Reference in New Issue