Brian May <br...@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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85lhxpex78.fsf...@benfinney.id.au
