Ambiguity in names of public objects (was: python-future: clean single-source support for Python 2/3)

[Ben Finney <ben+debian@benfinney.id.au>]

Brian May <brian@microcomaustralia.com.au> writes:

> Not a problem. It is rather confusing situation - having a module
> renamed from futures to concurrent.futures that contains a Future
> class, and having another future module that isn't remotely related.

For my part, I think the name “futures” is far too generic a name to use
for the highly domain-specific meaning of a concurrent-programming
library.

As the name of a “get the future of Python” library, it is more
understandable to any Python programmer, and so is a much better fit.

But I think the best option would have been for everyone to avoid that
name altogether as being far too ambiguous in meaning. Oh well, the
temptation is too strong for some people I guess.

> At least now we know it is something to watch out for.

Naming things is a very difficult problem in programming; perhaps one of
the hardest things to do correctly.

Humans tolerate, and even seek out, ambiguity in names; we even *prefer*
names that have multiple connotations. But when choosing names to be
accessed and managed by computers, ambiguity is poison. The two purposes
are always going to be in conflict, and naming things that need to
satisfy both will always be very difficult.

-- 
 \     “Creativity can be a social contribution, but only in so far as |
  `\            society is free to use the results.” —Richard Stallman |
_o__)                                                                  |
Ben Finney