4 ms·

Are you actually planning to lose Python 2 compatibility is porting to 3? It might make more sense to keep both if you can, if only because if you give up Pytho

by MBlume 10y ago

Are you actually planning to lose Python 2 compatibility is porting to 3? It might make more sense to keep both if you can, if only because if you give up Python 2, there'll be an intermediate period where the code won't run anywhere. Python six is a library that might help with targeting both

zzleeper 10y ago
Code that supports both py2 and py3 is often ugly and a pain to work with. I think your advice might be well intended, but if followed will end up with an overloaded dev. and no new progress being made (and all that for the five guys who still don't have py3 installed) Sorry to sound harsh, but I wish someone had told me that advice when I accepted to backport a py3 package to py2
- xapata 10y ago
  Wow! The community has turned a corner! :-) I don't believe 2-3 compatibility must be ugly (though it certainly can be), but I'm glad you believe what you said. If that makes sense.
  - JelteF 10y ago
    It's not only the compatibility that is ugly. It's also that python 2 code has a couple of ugly warts, such as the forced arguments for super(). The only way I'm supporting python 2 with my libraries is by running 3to2 and pasteurize (future package) over the python 3 source code. I really don't want to actually have source code that works on both, it's a pain to maintain. Although the future library should make it a lot nicer, but you still need a lot of ugly from __future__ imports as well.
    - xapata 10y ago
      I've been using 3.6 for some personal work and man are f-strings and ordered dicts wonderful. I don't want to go back.
      - renesd 10y ago
        1_000_000 times this.
      - TylerE 10y ago
        OrderedDict is just a stdlib import away in Py2.7.
        xapata 10y ago
        Yeah, but... those are ugly. ``m = {}`` is beautiful.
        Macha 10y ago
        dict == OrderedDict is a cpython implementation detail. Not doing the import is just leaving a footgun for yourself if you ever decide to try PyPy or VOC or similar.
        rspeer 10y ago
        I don't think it's much of a footgun, and I don't think it's limited to CPython. In Python 3.6, kwargs are ordered. In all versions of Python, kwargs are a dict. Therefore, in any implementation of Python 3.6, dicts are ordered. The dev team has stopped short of promising that dicts are ordered, but I can't see how one would realistically be harmed by assuming it to be true.
        xapata 10y ago
        The 3.6 CPython dict item storage algorithm was implemented in PyPy first.
- philh 10y ago
  > when I accepted to backport a py3 package to py2 I'd expect backporting from 3 to 2 to be more of a pain than porting from 2 to 3. You might have experience with both, but if not, this seems worth bearing in mind.
RedCrowbar 10y ago
If you are porting from 2.7 and don't require compatibility with earlier Python versions, then "future" [1] is a better, cleaner alternative to six. [1] https://pypi.python.org/pypi/future https://pypi.python.org/pypi/future

by MBlume 10y ago

zzleeper 10y ago

Code that supports both py2 and py3 is often ugly and a pain to work with. I think your advice might be well intended, but if followed will end up with an overloaded dev. and no new progress being made (and all that for the five guys who still don't have py3 installed) Sorry to sound harsh, but I wish someone had told me that advice when I accepted to backport a py3 package to py2

xapata 10y ago
Wow! The community has turned a corner! :-) I don't believe 2-3 compatibility must be ugly (though it certainly can be), but I'm glad you believe what you said. If that makes sense.
- JelteF 10y ago
  It's not only the compatibility that is ugly. It's also that python 2 code has a couple of ugly warts, such as the forced arguments for super(). The only way I'm supporting python 2 with my libraries is by running 3to2 and pasteurize (future package) over the python 3 source code. I really don't want to actually have source code that works on both, it's a pain to maintain. Although the future library should make it a lot nicer, but you still need a lot of ugly from __future__ imports as well.
  - xapata 10y ago
    I've been using 3.6 for some personal work and man are f-strings and ordered dicts wonderful. I don't want to go back.
    - renesd 10y ago
      1_000_000 times this.
    - TylerE 10y ago
      OrderedDict is just a stdlib import away in Py2.7.
      - xapata 10y ago
        Yeah, but... those are ugly. ``m = {}`` is beautiful.
        Macha 10y ago
        dict == OrderedDict is a cpython implementation detail. Not doing the import is just leaving a footgun for yourself if you ever decide to try PyPy or VOC or similar.
        rspeer 10y ago
        I don't think it's much of a footgun, and I don't think it's limited to CPython. In Python 3.6, kwargs are ordered. In all versions of Python, kwargs are a dict. Therefore, in any implementation of Python 3.6, dicts are ordered. The dev team has stopped short of promising that dicts are ordered, but I can't see how one would realistically be harmed by assuming it to be true.
        xapata 10y ago
        The 3.6 CPython dict item storage algorithm was implemented in PyPy first.
philh 10y ago
> when I accepted to backport a py3 package to py2 I'd expect backporting from 3 to 2 to be more of a pain than porting from 2 to 3. You might have experience with both, but if not, this seems worth bearing in mind.

RedCrowbar 10y ago

If you are porting from 2.7 and don't require compatibility with earlier Python versions, then "future" [1] is a better, cleaner alternative to six. [1] https://pypi.python.org/pypi/future https://pypi.python.org/pypi/future