[Anna Ravenscroft] >>I think this is a really good point. next() is supposed to get used, by >>coders, in regular code - so it shouldn't be __next__. I can understand the >>desire for both forms, although that seems it would clutter things up >>unnecessarily - particularly if the two do the same thing.
[Phillip Eby] > By this argument, we should be using ob.len() instead of len(ob), and > ob.iter() instead of iter(ob). Hey, no fair misstating her argument and then reducing it to the absurd. We're all aware that __len__ and __iter__ are supported by a wide variety of object types and are accessed through builtin functions provided expressly for that purpose. In contrast, we're all aware that next() applies only iterator objects, that it was designed for both direct and magic invocation, and that there is no corresponding builtin. This conversation is getting goofy. There is no underlying problem to be solved. Essentially, a couple of developers feel irritated by a perceived aberration from a naming convention. To assuage that irritation, they are willing to either 1) inflict pain on direct callers by cluttering the calling code with pairs of double underscores, or 2) add yet another builtin (needlessly bloating the namespace, adding another level of indirection, and burdening execution with an unnecessary global lookup). The cure is worse than the disease. IMO, the appropriate solution is to amend your understanding of the naming convention to only apply to methods whose normal invocation is exclusively magic and not called directly. Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
