Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <f457b1a3-3b80-43df-acbd-4617a5c591a0@googlegroups.com>
References: <2013101623133337485-owenjacobson@grimoireca> <roy-04EE5A.09525817102013@news.panix.com> <CAO32GkCb4u4aJW4QNohtLmGMr=LX=B-8D7qY2yh36vmUOC3OeA@mail.gmail.com> <mailman.1165.1382022472.18130.python-list@python.org> <f457b1a3-3b80-43df-acbd-4617a5c591a0@googlegroups.com>
Date: Fri, 18 Oct 2013 09:56:15 +1100
Subject: Re: Sexism in the Ruby community: how does the Python community manage it?
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1186.1382050591.18130.python-list@python.org>
Lines: 115
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:57000

On Fri, Oct 18, 2013 at 4:16 AM, Roy Smith <roy@panix.com> wrote:
> On Thursday, October 17, 2013 11:07:48 AM UTC-4, Chris Angelico wrote:
>> Module names should be  descriptive, not fancy.
>
> Interesting comment, on a mailing list for a language named after a snake=
, especially by a guy who claims to prefer an language named after a fish :=
-)

Heh, I do see the irony, but here's the deal: You have to get to know
a language somewhat before you can make an honest appraisal of it, and
that means knowing a lot more than its name. But you should be able to
know broadly what a module does based on its name, so that when you
see references to the module name in code, you have at least some idea
of what's going on. Here's a smattering of Python module names, from
the standard library:

8.1. datetime =97 Basic date and time types
8.11. pprint =97 Data pretty printer
9.6. random =97 Generate pseudo-random numbers
11.3. stat =97 Interpreting stat() results
12.6. sqlite3 =97 DB-API 2.0 interface for SQLite databases

All of them make it very clear what they're doing. Okay, so you can't
really learn much about sqlite3 other than that it interfaces with
sqlite3, whatever that is. If you had a module named "alsa", you
wouldn't know that that's a way of playing sound unless you know what
ALSA is elsewhere. But they're still linked fairly clearly with what
they do, on some level of "do". There are a few dodgier ones:

12.1. pickle =97 Python object serialization
(flavorful, fine once you know it, but a little unintuitive)
22.5. chunk =97 Read IFF chunked data
(heaps of things are chunked, but calling it "iff" would have been
just as confusing so there's probably no solution to this)

but, especially in networking, you can easily find what you want based
on an external requirement. Try searching the docs index for any
internet protocol name; if you get a hit, chances are very high that
it's a module that supports that. ("ip" is an exception, but "ipv4" or
"ipv6" will get you to the ipaddress module's description, at least.)

Pike is similar. Again, a few dodgy ones in the mix ("Remote" is an
RPC module, quite a few are buried inside a package like "Protocols"
or "Standards", etc), but by and large, module names follow the "Truly
Scrumptious" principle of sounding like what they are.

Now, to be fair, I should look at pypi.python.org and
modules.gotpike.org to compare against Ruby gems. Unfortunately I
can't pinpoint usage stats of any sort, but I can (in each case) get a
list of the most recently updated packages/modules, so hopefully the
packages that get updates are the ones people use. Python:

django-tornado
iso8601
fjd
mozilla-logger
dexy
vodafone-scraper
ipwhois
cashew
django-subdomains-handler
usethis-django-bootstrap

A few dodgy ones (I don't know what cashew does without clicking its
link), but mostly they're pretty descriptive. Pike modules are
organized into categories, which makes it too easy:

Public.Network.Pcap
Public.Tools.Language.Hyphenate
Database.EJDB
Public.Protocols.Jabber
Database.MongoDB

(The "Public" part is a packaging recommendation, and can basically be
ignored.) There are dodgy names around, though none have come up in
the five-most-recent-edits list here.

Now here's what I'm talking about, with Ruby. First off, any reference
to "gems" or precious stones in any way is given a special pass,
because of the environment (same as anything referencing Monty Python
would be in Python - it's not fair to compare against those). Some of
the names are descriptive:

mail
i18n
tzinfo
coffee-script
jquery-rails

But some are less clear:
nokogiri - an HTML/XML/etc parser (might mean something if I knew
Japanese, but all the docs are in English, so the name is a bit
orphanned; most languages prefer to name things in English, as it's
more internationally recognized)
arel - an "SQL AST manager" ??
cocaine - "A small library for doing (command) lines"
deface - lets you "customize ERB, Haml and Slim views"
polyamorous - though the description indicates that it's somewhat internal
therubyracer - interfaces with V8, the javascript engine
thor - "A scripting framework that replaces rake, sake and rubigen"

I know that all these are used, because they're all dependencies of a
particular gem I've used at work (Spree), and I got the list by
eyeballing this:

https://github.com/spree/spree_base_1_2/blob/master/Gemfile.lock

Most of them are names that I've seen getting installed during a Spree
installation.

This is what I mean. When module names aren't descriptive, code
becomes less clear. When language names aren't descriptive, very
little suffers.

ChrisA