[Python-Dev] PEP czar for PEP 3144?

[Nick Coghlan]

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