3 ms·

Libraries are a problem - it's difficult to switch unless all your dependencies are Python 3 compatible. The only ways to fix it are to either use an alternativ

Libraries are a problem - it's difficult to switch unless all your dependencies are Python 3 compatible. The only ways to fix it are to either use an alternative, or perhaps to fork or contribute patches to the project - both of which take up valuable time when your code is still functional under 2.7. I'm currently creating 2.7/3.3+ compatible code in whatever I create, but I'm still deploying to 2.7 hosts. For most of my projects this is due to just one package which has some Python 3 related bugs, so hopefully I can just flick the switch soon and use 3.4. It's only easy when your project depends on a few popular packages (eg. the top 200 where 86% are currently Python 3 compatible [1]), it's much more difficult if you've got a long list of dependencies. [1] https://python3wos.appspot.com/ https://python3wos.appspot.com/

mpdehaan2 11y ago
Yep, for me, distributions are the biggest thing holding things back right now, because the existing ones are out there, and will be deployed for a long time. If deploying a .com website, you can control your dependencies completely, and it's much easier than if you are deploying a system that must interact with existing systems the user/customer might have (for instance, management or monitoring apps). Thankfully that's not a huuuge class of systems, but it's what I typically work with :)
- aidos 11y ago
  I suspect most people don't have to deal with that issue (fortunately, because that must suck). Is there not some way of wrapping the entire binary with your distribution? If I was working in that space I think I'd probably choose a different language, if possible. As you say, it's not a problem for most of us as we get to dictate the platform.
anon3_ 11y ago
If you're wondering how you can do above / why it's not such a big deal: Python 2.7 has everything you need to write forward compatible code. It gives you all the __future__ dunders, the only extra thing you need is a compat module [1]: See kaleidoscope of examples: - https://www.google.com/search?q=site%3Agithub.com+compat.py+or+_compat.py https://www.google.com/search?q=site%3Agithub.com+compat.py+... - https://github.com/search?utf8=✓&q=extension%3Apy+"if+PY2"&type=Code https://github.com/search?utf8=✓&q=extension%3Apy+"if+PY2"&t... [1]: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

mpdehaan2 11y ago

Yep, for me, distributions are the biggest thing holding things back right now, because the existing ones are out there, and will be deployed for a long time. If deploying a .com website, you can control your dependencies completely, and it's much easier than if you are deploying a system that must interact with existing systems the user/customer might have (for instance, management or monitoring apps). Thankfully that's not a huuuge class of systems, but it's what I typically work with :)

aidos 11y ago
I suspect most people don't have to deal with that issue (fortunately, because that must suck). Is there not some way of wrapping the entire binary with your distribution? If I was working in that space I think I'd probably choose a different language, if possible. As you say, it's not a problem for most of us as we get to dictate the platform.

anon3_ 11y ago

If you're wondering how you can do above / why it's not such a big deal: Python 2.7 has everything you need to write forward compatible code. It gives you all the __future__ dunders, the only extra thing you need is a compat module [1]: See kaleidoscope of examples: - https://www.google.com/search?q=site%3Agithub.com+compat.py+or+_compat.py https://www.google.com/search?q=site%3Agithub.com+compat.py+... - https://github.com/search?utf8=✓&q=extension%3Apy+"if+PY2"&type=Code https://github.com/search?utf8=✓&q=extension%3Apy+"if+PY2"&t... [1]: http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/