Path: csiph.com!usenet.pasdenom.info!news.franciliens.net!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!81.171.88.16.MISMATCH!hq-usenetpeers.eweka.nl!hq-usenetpeers.eweka.nl!bcyclone02.am1.xlned.com!bcyclone02.am1.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Python Iterables struggling using map() built-in
Date: Wed, 10 Dec 2014 12:48:06 -0500
References: <004e01d01173$e1641c10$a42c5430$@gmail.com> <m61roh$i5m$1@ger.gmane.org> <CALwzid=79=i3Sez3fQYV7xU2bEAL4_ohPqxhuYj59Y5ihXk1Zg@mail.gmail.com> <mailman.16685.1417976998.18130.python-list@python.org> <5484e3d8$0$13013$c3e8da3$5496439d@news.astraweb.com> <roy-3F4751.19122007122014@news.panix.com> <54866372$0$12991$c3e8da3$5496439d@news.astraweb.com> <m65vrc$j0t$1@ger.gmane.org> <mailman.16776.1418155635.18130.python-list@python.org> <54878f8a$0$13010$c3e8da3$5496439d@news.astraweb.com> <roy-0FD505.21442409122014@news.panix.com> <54881159$0$2817$c3e8da3$76491128@news.astraweb.com> <CALwzidnU9nLTTTzOqg+MxeUbDixjEx_sSi=Tsy4MPaFuy--HUA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <CALwzidnU9nLTTTzOqg+MxeUbDixjEx_sSi=Tsy4MPaFuy--HUA@mail.gmail.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.16823.1418233709.18130.python-list@python.org>
Lines: 52
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:82304

On 12/10/2014 11:46 AM, Ian Kelly wrote:

> I don't particularly have a problem with functions having attributes,
> e.g. I think itertools.chain.from_iterable is just peachy. There is a
> downside though, which is that making those functions attributes of
> another function rather than of the module

Itertools.chain is a class, not a function.  Chain.from_iterable is an 
*alternate constructor* for instances of the class, just as 
dict.fromkeys is an alternate constructor for dict instances.

It is true that if itertools were written in python, chain and the other 
classes would likely be written as generator functions, so tha analogy 
would not apply.

> defeats the dir() function for that module.

And it is also true that dir(__builtins__) does not show dict.fromkeys.

> Likewise the generated help for the help() function,
> unless care is taken to explicitly mention the existence of those
> functions in either the doc string for the module

help(it.chain) lists
  |  from_iterable(...) from builtins.type
  |      chain.from_iterable(iterable) --> chain object
  |
  |      Alternate chain() contructor taking a single iterable argument
  |      that evaluates lazily.

help(dict)
  |  fromkeys(iterable, value=None, /) from builtins.type
  |      Returns a new dict with keys from iterable and values equal to 
value.

> Thirdly, IDEs with code completion features may simply fail to
> notice that these alternate versions of the function exist.

I don't know what you mean here.  In Idle
 >>> it.chain.  --> completion box with from_iterable
 >>> dict.   --> completion box that includes fromkeys

None of the above is to say that alternate constructors for classed are 
not a bit awkward.  I believe this was recognized when dict.fromkeys was 
added.  But it was considered less awkward than the alternatives: 1. do 
not add the functionality; 2. further overload the main (__init__) 
constructor; 3. add a independent function.  Anyway, they exist, are an 
accepted pattern among core devs, and will probably increase in number.

-- 
Terry Jan Reedy