RetroSearch Browse

Mon Mar 19 22:50:22 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-March/117814.html

Guido van Rossum wrote:
> On Mon, Mar 19, 2012 at 1:13 PM, Ethan Furman wrote:
>> Nothing wrong in and of itself.  It just seems to me that if we have several
>> functions that deal with ip addresses/networks/etc, and all but one return
>> iterators, that one is going to be a pain... 'Which one returns a list
>> again? Oh yeah, that one.'
> 
> It depends on whether they really are easy to confuse. If they are,
> indeed that feels like poor API design. But sometimes the only time
> two things seem confusingly similar is when you have not actually
> tried to use them.

Heh -- true, I have not tried to use them (yet) -- just offering another 
viewpoint.  ;)

>> Granted it's mostly a stylistic preference for consistency.
> 
> And remember that consistency is good in moderation, but if it becomes
> a goal in itself you may have a problem.

While I agree that consistency as a goal in and of itself is not good, I 
consider it more important than 'moderation' implies; in my own code I 
try to only be inconsistent when there is a good reason to be.

To me, "it's already a list" isn't a good reason -- yes, that's easier 
for the library author, but is it easier for the library user?  What is 
the library user gaining by having a list returned instead of an iterator?

Of course, the flip-side also holds:  what is the library user losing by 
getting an iterator when a list was available?

When we way the pros and cons, and it comes down to a smidgeon of 
performance in trade for consistency [1], I would vote for consistency.

~Ethan~

[1] I'm assuming that 'iter(some_list)' is a quick operation.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-March/117814.html below:

[Python-Dev] PEP czar for PEP 3144?