[ftputil] Dropping Python 2 support

Stefan Schwarzer sschwarzer at sschwarzer.net
Sun Jul 9 16:02:32 CEST 2017


Hello,

As the subject implies, I'd like to drop support for Python 2
in ftputil.

My current plan is to release a version 3.4 that will fix
ticket 109 [1] and add deprecation warnings when ftputil is
run under Python 2. Sometime later this year I'd like to
release ftputil 4.0, which will only support Python 3
(probably Python 3.5 and later).

If you followed the development of ftputil over the years,
you'll have noticed that I usually care a lot about backward
compatibility, so it was difficult for me to seriously
consider the idea of dropping Python 2 support.

There are several reasons for the plan:

- I'm migrating the ftputil tests from my custom mock code
  (from 2002!) to `unittest.mock`. If I don't have to port
  the Python-2-specific tests, this obviously is less work
  for me.

- Some people asked for support of asynchronous functionality
  in ftputil (see ticket 94 [2]) and I'd like to see this,
  too. Of course this will be much easier in Python 3.4 and
  later, where the `asyncio` module has been added [3].
  Additionally, Python 3.5 adds the `async` and `await`
  syntax [4] which makes asynchronous programming more
  straightforward.

- Python 3.2 added `functools.lru_cache` [5] which could be
  used instead of the LRU cache module that's currently
  included in ftputil.

- I'd very much like to get rid of some backward
  compatibility hacks [6, 7]. There's also code in ftputil
  to make sure that the underlying ftplib library gets
  byte strings in Python 2 and unicode strings in Python 3.
  The different APIs of ftplib in Python 2 and 3 were a
  major source of headaches when adding support for Python 3.

- I'd like to be able to use new syntax and idioms that
  aren't possible in Python 2, including Python 2.7.

- And of course, Python 3 usage is far more widespread now
  than it was when ftputil dropped support for Python 2.4
  and 2.5 in 2013 and kept supporting Python 2.6 and 2.7.

The last straw for _seriously_ considering the move to only
Python 3 was an article from Nick Coghlan [8]. I think the
article takes into account the common worries about dropping
Python 2 support. By the way, these are the same worries
that came up when I was about to drop support for Python 2.4
and 2.5.

The article also points out an issue that also applies to
me: I work on ftputil in my free time and of course it's
easier (and more fun) to work on ftputil if I don't have to
watch out for compatibility with Python 2. Mainly the
thoughts whether to keep Python 2 support have held me back
from working on ticket 98 [9]. In turn, as long as ticket 98
isn't finished I'm very hesitant to add functionality, for
which of course I want to have automated tests.

I'm open to listen to arguments that may change my mind on
Python 2 support, but these arguments must be _very_
convincing. Before even trying to convince me, _please_ read
Nick's article [8] in full. That said, I highly recommend
you read the article even if you have no problems with
ftputil dropping Python 2 support.

Please also keep in mind that even if ftputil 4.0 supports
only Python 3, you can of course still download and use
older ftputil releases to work with a Python 2 codebase if
you really can't avoid it.

[1] http://ftputil.sschwarzer.net/trac/ticket/109
[2] http://ftputil.sschwarzer.net/trac/ticket/94
[3] https://docs.python.org/3/whatsnew/3.4.html#asyncio
[4] https://docs.python.org/3/whatsnew/3.5.html#pep-492-coroutines-with-async-and-await-syntax
[5] https://docs.python.org/3/whatsnew/3.2.html#functools
[6] http://ftputil.sschwarzer.net/trac/browser/ftputil/session_adapter.py
[7] http://ftputil.sschwarzer.net/trac/browser/ftputil/socket_file_adapter.py
[8] http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
[9] http://ftputil.sschwarzer.net/trac/ticket/98

Best regards,
Stefan


More information about the ftputil mailing list