3 ms·
I've found exactly the same thing. As someone writing applications using Python 3, I found the switch to be easy and I haven't had any problems with libraries.
by aidos 12y ago
I've found exactly the same thing.
As someone writing applications using Python 3, I found the switch to be easy and I haven't had any problems with libraries. I've switched from some of the old ones I was using to more modern alternatives that are being actively developed.
It annoys me that there are people on Python 2 that haven't really tried to make the switch and stand on the sideline shouting insults at Python 3. It's a tremendously self destructive thing to do for all involved.
To anyone looking to get started with Python, there's no real reason to start with Python 2 these days.
- SudoAlex 12y agoLibraries 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 12y agoYep, 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 12y agoI 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_ 12y agoIf 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/
- ekimekim 12y agoI'll get downvotes for this, but my reason for sticking with python2 isn't library support, it's that I prefer python2's strings. Sure, it made unicode handling less painful in cases where encodings are always known and everything should be in unicode, but it makes things much harder for people working with bytes interfaces that want to treat all non-ascii bytes agnostically.
- aidos 12y agoBut Python 2 strings are bytes. So in Python 3 just use bytes everywhere. Or am I misunderstanding something?