On 10 June 2016 at 07:29, Pavol Lisy <pavol.lisy@gmail.com> wrote:
It is why I like to see some guidlines how to do it. One practical possibility is (sorry for blasphemy) to (temporary!) drop support for python3.
That's certainly an option. If you're writing an in-house application, then it's entirely reasonable to decide not to support a version of Python you don't plan to go to. If you're writing in-house libraries, saying "our company is not yet ready to support Python 3 for our internal code" is perfectly reasonable. If you're publishing code for external use, you have to decide whether alienating customers who want Python 3 support is worth it - that's again your decision. Only you know how many such customers you have. There is no requirement on anyone to support Python 3. However, there's a growing trend [1] to think of public software that doesn't support Python 3 as stagnant, and for people to look for "more up to date" replacements. That's something you have to consider when deciding not to support Python 3. Paul [1] We can debate endlessly on how fast the growth is. But even Twisted, the most highly visible project that I know of to struggle with supporting Python 3, has felt enough pressure to invest massive amounts of time in the porting effort.