[Python-Dev] PEP czar for PEP 3144?
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