iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Adding MAL's comment about next() vs. __next__().

This commit is contained in:
Guido van Rossum 2001-04-26 13:39:59 +00:00
parent 701fba5cdb
commit bc657d06b6
1 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
pep-0234.txt
View File

@ -102,7 +102,13 @@ C API Specification
special name. On the other hand, this would suggest that there special name. On the other hand, this would suggest that there
should also be a primitive operation next(x) that would call should also be a primitive operation next(x) that would call
x.__next__(), and this just looks like adding complexity without 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 Python API Specification