Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.002 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'programmer': 0.03; 'parameters': 0.04; 'subject:Python': 0.06; 'attributes': 0.09; 'function,': 0.09; 'latter': 0.09; 'namespace': 0.09; 'os.path': 0.09; 'referenced': 0.09; 'subject:using': 0.09; 'works.': 0.09; 'creates': 0.14; '"from': 0.16; '"i': 0.16; 'attributes,': 0.16; 'collections': 0.16; 'downside': 0.16; 'extension,': 0.16; 'grouped': 0.16; 'modules,': 0.16; 'namespace,': 0.16; 'namespace.': 0.16; 'top-level': 0.16; 'wanted.': 0.16; ':-)': 0.16; 'wrote:': 0.18; 'library': 0.18; 'wed,': 0.18; 'module': 0.19; 'import': 0.22; 'separate': 0.22; "aren't": 0.24; 'documented': 0.24; 'stick': 0.24; '>': 0.26; 'header:In-Reply- To:1': 0.27; 'point': 0.28; 'function': 0.29; 'wonder': 0.29; 'dec': 0.30; 'designer': 0.30; 'moved': 0.30; 'message- id:@mail.gmail.com': 0.30; "i'm": 0.30; '-0700,': 0.31; "d'aprano": 0.31; 'idea,': 0.31; 'steven': 0.31; 'another': 0.32; 'open': 0.33; 'problem': 0.35; 'something': 0.35; 'point.': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'functions.': 0.36; 'module.': 0.36; 'should': 0.36; 'detail': 0.37; 'expected': 0.38; 'e.g.': 0.38; 'to:addr:python-list': 0.38; 'pm,': 0.38; 'rather': 0.38; 'expect': 0.39; 'does': 0.39; 'itself': 0.39; 'though,': 0.39; 'to:addr:python.org': 0.39; 'enough': 0.39; 'how': 0.40; 'ian': 0.60; 'skip:\xc2 10': 0.60; 'new': 0.61; 'browser': 0.61; 'making': 0.63; 'group,': 0.63; 'provide': 0.64; 'great': 0.65; 'incorporate': 0.68; 'low': 0.83; 'demonstrates': 0.84; 'median': 0.84; 'returns.': 0.84; 'cognitive': 0.91; 'hand,': 0.93; 'suited': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=PiUfThuPwFF+MrjlS3/o1q4eJ1AwVDaqZAHr/0WLXQw=; b=py7VL2MaV9Xa1bX6s37yTBlg0EyYisCReL/OAM0v5kIw+yNvmHz9RhiHqn+JTxCG2y KujkHm0Ky1bsydtty4dYOWwqk6/K0Vj/PgXdeyRHYAaTtaQN+Xm1gAqka6tJfV0S8/t/ +ty2mdR7eyQ9G2341PPRK+FWWbgHXp9xhApV2vNbss0iE4XyWgnYDmnmfnihFzJZ0Lj/ 3q50aciVzKWGXaWzqieKzfKIkjrwyger1gNgAoCUgod8Wun+phHXOMnUoii3Ls2GVd0+ EwZVcmAdE/qklXEEsgydh1dqrI6/y199jX5LLFpbWKDNhjBc/GCSZ6cXfblHgluNaRBq J1dA== X-Received: by 10.68.221.34 with SMTP id qb2mr21036454pbc.72.1418335257536; Thu, 11 Dec 2014 14:00:57 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <54891733$0$2817$c3e8da3$76491128@news.astraweb.com> References: <004e01d01173$e1641c10$a42c5430$@gmail.com> <5484e3d8$0$13013$c3e8da3$5496439d@news.astraweb.com> <54866372$0$12991$c3e8da3$5496439d@news.astraweb.com> <54878f8a$0$13010$c3e8da3$5496439d@news.astraweb.com> <54881159$0$2817$c3e8da3$76491128@news.astraweb.com> <54891733$0$2817$c3e8da3$76491128@news.astraweb.com> From: Ian Kelly Date: Thu, 11 Dec 2014 15:00:16 -0700 Subject: Re: Python Iterables struggling using map() built-in To: Python Content-Type: multipart/alternative; boundary=e89a8ff2433b32b0bd0509f7e958 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 99 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1418335266 news.xs4all.nl 2888 [2001:888:2000:d::a6]:37597 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:82388 --e89a8ff2433b32b0bd0509f7e958 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 10, 2014 at 9:01 PM, Steven D'Aprano wrote: > > On Wed, 10 Dec 2014 09:46:55 -0700, 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 defeats the dir() function > > for that module. > > I think you are missing the point of namespaces :-) > > When I call dir(os), I see os.path, but I don't see the names in os.path. > That is working as designed. I don't think I'm missing the point. os.path is a module. That makes it well suited for a namespace, because that's what modules are designed and expected to provide: the implementation of namespaces. A function, on the other hand, is not well suited to be a namespace, because it's not expected to provide one. When I see a new function, I don't think "I should check what attributes it has." Instead, I wonder about what parameters it takes and what it returns. I expect to be able to open up my web browser and go to the library documentation for the os.path module. I don't expect to find a separate page for statistics.median, because the docs are organized around modules, not functions. Would the median function itself be documented in the statistics page, in the statistics.median page, or redundantly in both? I expect to be able to import modules, and by extension, namespaces. "import os.path" works. "import statistics.median.low" would return an error, as would "from statistics.median import low as median", if that were the only function I wanted. In the latter case I would have to do something like "from statics import median; median = median.low". That's not just ugly; it also demonstrates how the programmer needs to remember and incorporate the detail that this namespace does not work like other namespaces. > As the designer of the module I thought that median_low and median_high > were important enough to include but not important enough to stick in the > main module namespace. To me this sounds backward. Namespaces are a great idea, but at the same time they also create cognitive burden. One creates a namespace because the contents are important enough to be referenced as a group, not because they aren't as important as the other things they're grouped with. The reason the collections ABCs were moved into collections.abc wasn't because they weren't important enough to be in the top-level collections module. --e89a8ff2433b32b0bd0509f7e958 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 10, 2014 at 9:01 PM, Steven D'Aprano <<= a href=3D"mailto:steve@pearwood.info">steve@pearwood.info> wrote:>
> On Wed, 10 Dec 2014 09:46:55 -0700, Ian Kelly wrote:
><= br>> > 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 thos= e functions attributes of
> > another function rather than of the = module defeats the dir() function
> > for that module.
>
= > I think you are missing the point of namespaces :-)
>
> Wh= en I call dir(os), I see os.path, but I don't see the names in os.path.=
> That is working as designed.

I don't think I'm= missing the point. os.path is a module. That makes it well suited for a na= mespace, because that's what modules are designed and expected to provi= de: the implementation of namespaces. A function, on the other hand, is not= well suited to be a namespace, because it's not expected to provide on= e. When I see a new function, I don't think "I should check what a= ttributes it has." Instead, I wonder about what parameters it takes an= d what it returns.

I expect to be able to open up = my web browser and go to the library documentation for the os.path module. = I don't expect to find a separate page for statistics.median, because t= he docs are organized around modules, not functions.=C2=A0 Would the median= function itself be documented in the statistics page, in the statistics.me= dian page, or redundantly in both?

I expect to be = able to import modules, and by extension, namespaces. =C2=A0"import os= .path" works. =C2=A0"import statistics.median.low" would ret= urn an error, as would "from statistics.median import low as median&qu= ot;, if that were the only function I wanted. In the latter case I would ha= ve to do something like "from statics import median; median =3D median= .low". That's not just ugly; it also demonstrates how the programm= er needs to remember and incorporate the detail that this namespace does no= t work like other namespaces.

> As the designer= of the module I thought that median_low and median_high
> were impor= tant enough to include but not important enough to stick in the
> mai= n module namespace.

To me this sounds backward. Na= mespaces are a great idea, but at the same time they also create cognitive = burden. One creates a namespace because the contents are important enough t= o be referenced as a group, not because they aren't as important as the= other things they're grouped with. The reason the collections ABCs wer= e moved into collections.abc wasn't because they weren't important = enough to be in the top-level collections module.
--e89a8ff2433b32b0bd0509f7e958--