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

2014-02-05 Thread Ben Finney
Brian May 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 us

Re: python-future: clean single-source support for Python 2/3

2014-02-05 Thread Brian May
On 5 February 2014 19:05, Thomas Goirand wrote: > Just a quick message to say sorry for being the source of this big > confusion between future and futures (with "s"). > Not a problem. It is rather confusing situation - having a module renamed from futures to concurrent.futures that contains a F

Re: python-future: clean single-source support for Python 2/3

2014-02-05 Thread Thomas Goirand
On 02/05/2014 06:04 AM, Brian May wrote: > Hello, > > Has anybody considered packaging python-future for Debian? > > No, I am not talking about python-futures, python-concurrency.futures, > or anything relating to #736523 (the first message in this bug had > rather confused at first). > > Rather

python-future: clean single-source support for Python 2/3

2014-02-04 Thread Brian May
Hello, Has anybody considered packaging python-future for Debian? No, I am not talking about python-futures, python-concurrency.futures, or anything relating to #736523 (the first message in this bug had rather confused at first). Rather I am talking about: http://python-future.org/ "future is