9 ms·

This call has been made a while back, and it makes perfect sense. Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no re

by yuvadam 10y ago

This call has been made a while back, and it makes perfect sense. Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. Sure legacy projects still need support and for that they get the 1.11 LTS, but otherwise it's really time to move on.

hueving 10y ago
Easy to say when you don't depend on C extensions only compatible with 2.7.
- gkya 10y ago
  How hard it is to port a C extension? I don't really know the APIs, but is it impossible to transform by a script?
  - novocaine 10y ago
    My experience is that it is drastically easier to port C extensions than to port python code itself - the C API hasn't really changed a lot and it's usually very easy to reason about C code due to it being more strongly typed than python. The only reason why it might be hard is you are unfamiliar with the extension's code and/or C
  - throwawayish 10y ago
    Not hard. You can support 3 and 2 in the same file without much hassle. Practical example: https://github.com/zopefoundation/BTrees/blob/master/BTrees/_compat.h https://github.com/zopefoundation/BTrees/blob/master/BTrees/... https://github.com/zopefoundation/BTrees/blob/master/BTrees/BTreeModuleTemplate.c https://github.com/zopefoundation/BTrees/blob/master/BTrees/... There are a couple #if PY3K, but not much, really. I ported a bunch of extension modules, total a couple thousand LOC, and it was pretty much a matter of reading the docs (see guide at https://docs.python.org/3/howto/cporting.html https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.
  - deleted 10y ago
    [deleted]
- nsomaru 10y ago
  You're calling code that depends on C extensions from directly inside the request-response cycle? One possible solution would be to offload this work into a celery worker which can call python2 as necessary.
  - osullivj 10y ago
    I code against both Django and Tornado. My Tornado based HTTP servers call C extension while they're handling GETs and POSTs. And that's why I'm staying on 2.7.8 until a customer pays me to port to 3.
    - Siecje 10y ago
      I'm curious why 2.7.8? What is preventing you from using 2.7.9+?
      - osullivj 10y ago
        2.7.8 was the latest 2.x when I built the current codebase. Currently I'm testing before a cloud launch. Fixing bugs in my product's functionality is a higher priority than porting to the latest 2.7
        tedmiston 10y ago
        Python 2.7.9 Release Date: 2014-12-10 https://www.python.org/downloads/release/python-279/ https://www.python.org/downloads/release/python-279/
        nostrademons 10y ago
        2 years is not an unusual time between starting product development and seeing any sort of major customer uptake, and if you're in that time period, your priority really should be getting the customers rather than futzing with code migrations.
        10y ago
- rbanffy 10y ago
  How many are still at that stage?
- takeda 10y ago
  Is really not that hard to make C extension support Python 3, you're either using an extension that is no longer maintained, or its author(s) are stubborn, which is a different kind of problem. Making code compatible with python2.7 onward means that you can't use any new features from 3+ and the code is plain ugly, I don't know if you wrote 2/3 compatible code, it is not as enjoyable to do. I think Django's approach where the LTS will still work on 2.7 (and LTS is for 3 years, which is until python2 itself stop being maintained) is fair. You still have 3 years to fix things and if you want to use latest Django and be cutting edge, you probably should use latest Python as well.
- flukus 10y ago
  Wouldn't the problem be that you're already relying on unmaintained software?
coldtea 10y ago
>and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. How about millions of lines of code in your company in Python 2, and several Python 2 based services and websites? Why on earth will you go to Python 3 at huge rewriting costs? To get some fancy syntactic sugar and improved unicode?
- BHSPitMonkey 10y ago
  Why can't your Python 2 services talk to your Python 3 web app?
  - coldtea 10y ago
    Why should I maintain code, servers and libs in 2 versions of a backend programming language?
    - agildehaus 10y ago
      Because one is essentially EOL?
      - coldtea 10y ago
        Well, I'm for user driven EOL, as opposed to top-down, we-know-better EOLining. And the latter doesn't work so well thus far for Python 3.
        parzivalm 10y ago
        I think you see this argument used a lot when it comes to Python 3 about it not working so well. I don't see the maintainers changing their minds about EOL on python 2 so either switch to Python 3 or to another language. There is so much toxicity around the Python community because of people thinking they are entitled to have everyone still support Python 2.
        TeMPOraL 10y ago
IndianAstronaut 10y ago
>Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. Except that there are still some critical packages that aren't on Python 3 yet. Not to mention a lot of functionality breaks even if the libraries do exist, which means you have to code things up quite differently sometimes.
- faitswulff 10y ago
  What critical packages still need to be ported to Python 3? Might be a fun project if they're open source.
  - squeaky-clean 10y ago
    For me, the google api client libraries, and AWS Lambda. That last one isn't totally Django related, but we use it for certain service calls, and it'd be nicer to be able to maintain one version of the language across the django app and related services. We ended writing a service in PHP to use Google's APIs, and are mostly using Scala or JS instead of Python for the Lambda services because this project is basically a ton of unicode mangling, and you can pry Python 3's sane unicode support from my cold dead hands! But the libraries still aren't totally perfect. It just takes on dependency being out of date to screw your plans.
    - Alex3917 10y ago
      The Google API Client is at least Python 3.4 compatible: https://github.com/google/google-api-python-client/ https://github.com/google/google-api-python-client/ I see only one Py3 bug is the open issues. And I think even their ancillary library Python Flags is now officially Py3 compatible, even though there has been a Py3 fork of it for years.
      - squeaky-clean 10y ago
        Nice! Looks that was just added in December, prior to that they had a statement saying it would probably work in 3.3+ but wasn't tested. I didn't mean the one literally called google-api-python-client though (forgot they had that, ha). The googleads-python-lib is the critical one for me. PyPI says it supports 3+, but do one search in the repo for "print" and you'll see that's clearly not true. Looking through the history, seems like they've claimed support for it for a while. We've tried it twice and had issues both times, though I never tried it in Py2, so maybe it just has problems in general.

by yuvadam 10y ago

hueving 10y ago

Easy to say when you don't depend on C extensions only compatible with 2.7.

gkya 10y ago
How hard it is to port a C extension? I don't really know the APIs, but is it impossible to transform by a script?
- novocaine 10y ago
  My experience is that it is drastically easier to port C extensions than to port python code itself - the C API hasn't really changed a lot and it's usually very easy to reason about C code due to it being more strongly typed than python. The only reason why it might be hard is you are unfamiliar with the extension's code and/or C
- throwawayish 10y ago
  Not hard. You can support 3 and 2 in the same file without much hassle. Practical example: https://github.com/zopefoundation/BTrees/blob/master/BTrees/_compat.h https://github.com/zopefoundation/BTrees/blob/master/BTrees/... https://github.com/zopefoundation/BTrees/blob/master/BTrees/BTreeModuleTemplate.c https://github.com/zopefoundation/BTrees/blob/master/BTrees/... There are a couple #if PY3K, but not much, really. I ported a bunch of extension modules, total a couple thousand LOC, and it was pretty much a matter of reading the docs (see guide at https://docs.python.org/3/howto/cporting.html https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.
- deleted 10y ago
  [deleted]
nsomaru 10y ago
You're calling code that depends on C extensions from directly inside the request-response cycle? One possible solution would be to offload this work into a celery worker which can call python2 as necessary.
- osullivj 10y ago
  I code against both Django and Tornado. My Tornado based HTTP servers call C extension while they're handling GETs and POSTs. And that's why I'm staying on 2.7.8 until a customer pays me to port to 3.
  - Siecje 10y ago
    I'm curious why 2.7.8? What is preventing you from using 2.7.9+?
    - osullivj 10y ago
      2.7.8 was the latest 2.x when I built the current codebase. Currently I'm testing before a cloud launch. Fixing bugs in my product's functionality is a higher priority than porting to the latest 2.7
      - tedmiston 10y ago
        Python 2.7.9 Release Date: 2014-12-10 https://www.python.org/downloads/release/python-279/ https://www.python.org/downloads/release/python-279/
        nostrademons 10y ago
        2 years is not an unusual time between starting product development and seeing any sort of major customer uptake, and if you're in that time period, your priority really should be getting the customers rather than futzing with code migrations.
        10y ago
rbanffy 10y ago
How many are still at that stage?
takeda 10y ago
Is really not that hard to make C extension support Python 3, you're either using an extension that is no longer maintained, or its author(s) are stubborn, which is a different kind of problem. Making code compatible with python2.7 onward means that you can't use any new features from 3+ and the code is plain ugly, I don't know if you wrote 2/3 compatible code, it is not as enjoyable to do. I think Django's approach where the LTS will still work on 2.7 (and LTS is for 3 years, which is until python2 itself stop being maintained) is fair. You still have 3 years to fix things and if you want to use latest Django and be cutting edge, you probably should use latest Python as well.
flukus 10y ago
Wouldn't the problem be that you're already relying on unmaintained software?

coldtea 10y ago

>and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. How about millions of lines of code in your company in Python 2, and several Python 2 based services and websites? Why on earth will you go to Python 3 at huge rewriting costs? To get some fancy syntactic sugar and improved unicode?

BHSPitMonkey 10y ago
Why can't your Python 2 services talk to your Python 3 web app?
- coldtea 10y ago
  Why should I maintain code, servers and libs in 2 versions of a backend programming language?
  - agildehaus 10y ago
    Because one is essentially EOL?
    - coldtea 10y ago
      Well, I'm for user driven EOL, as opposed to top-down, we-know-better EOLining. And the latter doesn't work so well thus far for Python 3.
      - parzivalm 10y ago
        I think you see this argument used a lot when it comes to Python 3 about it not working so well. I don't see the maintainers changing their minds about EOL on python 2 so either switch to Python 3 or to another language. There is so much toxicity around the Python community because of people thinking they are entitled to have everyone still support Python 2.
      - TeMPOraL 10y ago

IndianAstronaut 10y ago

>Python 2 is slowly being EOL'd and if you're starting a brand new Django project there's no reason on earth you should choose Python 2 anymore. Except that there are still some critical packages that aren't on Python 3 yet. Not to mention a lot of functionality breaks even if the libraries do exist, which means you have to code things up quite differently sometimes.

faitswulff 10y ago
What critical packages still need to be ported to Python 3? Might be a fun project if they're open source.
- squeaky-clean 10y ago
  For me, the google api client libraries, and AWS Lambda. That last one isn't totally Django related, but we use it for certain service calls, and it'd be nicer to be able to maintain one version of the language across the django app and related services. We ended writing a service in PHP to use Google's APIs, and are mostly using Scala or JS instead of Python for the Lambda services because this project is basically a ton of unicode mangling, and you can pry Python 3's sane unicode support from my cold dead hands! But the libraries still aren't totally perfect. It just takes on dependency being out of date to screw your plans.
  - Alex3917 10y ago
    The Google API Client is at least Python 3.4 compatible: https://github.com/google/google-api-python-client/ https://github.com/google/google-api-python-client/ I see only one Py3 bug is the open issues. And I think even their ancillary library Python Flags is now officially Py3 compatible, even though there has been a Py3 fork of it for years.
    - squeaky-clean 10y ago
      Nice! Looks that was just added in December, prior to that they had a statement saying it would probably work in 3.3+ but wasn't tested. I didn't mean the one literally called google-api-python-client though (forgot they had that, ha). The googleads-python-lib is the critical one for me. PyPI says it supports 3+, but do one search in the repo for "print" and you'll see that's clearly not true. Looking through the history, seems like they've claimed support for it for a while. We've tried it twice and had issues both times, though I never tried it in Py2, so maybe it just has problems in general.