[Python-Dev] PEP czar for PEP 3144? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Mar 19 04:04:48 CET 2012

On Mon, Mar 19, 2012 at 12:44 PM, Peter Moody <pmoody at google.com> wrote:

On Mon, Mar 12, 2012 at 9:15 AM, Peter Moody <pmoody at google.com> wrote:

- iterable APIs should consistently produce iterators (leaving users free to wrap list() around the calls if they want the concrete realisation) I might've missed earlier discussion somewhere, but can someone point me at an example of an iteratable api in ipaddr/ipaddress where an iterator isn't consistently produced?

There was at least one that I recall, now to find it again...

And searching for "list" in the PEP 3144 branch source highlights subnet() vs iter_subnets() as the main problem child:

https://code.google.com/p/ipaddr-py/source/browse/branches/3144/ipaddress.py#1004

A single "subnets()" method that produced the iterator would seem to make more sense (with a "list()" call wrapped around it when the consumer really wants a concrete list).

There are a few other cases that produce a list that are less clearcut.

I think summarising the address range could be converted to an iterator, since the "networks" accumulation list doesn't get referenced by the summarising algorithm.

Similarly, there doesn't appear to be a compelling reason for "address_exclude" to produce a concrete list (I also noticed a couple of "assert True == False" statements in that method for "this should never happen" code branches. An explicit "raise AssertionError" is a better way to handle such cases, so the code remains present even under -O and -OO)

Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case.

Cheers, Nick.

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list