There's a lot of improvements in 3, but I'm sad to say I'm really hung up on print (and that's why I'm still using 2.x).
Eventually, I guess. If I have to.
Python 3 Wall of Shame
61–70 of 80 posts
Re: Python 3 Wall of Shame
#62At first I was going to say that we need some sort of dependency graph to focus on what needs to be ported first. As a Plone developer, I see lots of stuff down the stack that needs to be done before Plone could move to Python 3. However, simply ranking based on number of downloads seems to do a pretty good prioritization.
Out of the first 10 packages that haven't been ported to Python 3, I think nearly all are needed for Plone. (Although things like virtualenv are not a requirement for Plone, they are widely used in Plone development)
Re: Python 3 Wall of Shame
#63I've been doing a ton of Python work lately. Frankly, in my experience, Python 3 is more of a pain to develop with, primarily due to two factors: * Encoding specifications required. * maps/reduces returning iterators objects instead of a list. Having to call list() on anything I map is just a pain. I don't plan to switch to Python 3 until a compelling reason shows up. 2.7 works great for what I do. The real story her…
I like that map and reduce return iterators; it lets me map over a huge collection even if I just want the first few.
Re: Python 3 Wall of Shame
#64There's a lot of improvements in 3, but I'm sad to say I'm really hung up on print (and that's why I'm still using 2.x). Eventually, I guess. If I have to.
Yeah, there's no good reason to change print. Sure, making it a function can be handy; but they should recognize the "print foo" syntax and compile it to a function call.
Re: Python 3 Wall of Shame
#65The real issue is that for both developers and library maintainers, moving to Python3 entails a lot of aggravation for a comparatively small net benefit.
Porting is actually fairly trivial in many cases. If you go and look at most of the porting stories for Python 3, you'll find the authors saying "I was worried it would be hard... but it was really easy".
I have the impression that translating the Python is easy (it was for the one project I did), but the C bindings are more of a pain.
Re: Python 3 Wall of Shame
#66I've been doing a ton of Python work lately. Frankly, in my experience, Python 3 is more of a pain to develop with, primarily due to two factors: * Encoding specifications required. * maps/reduces returning iterators objects instead of a list. Having to call list() on anything I map is just a pain. I don't plan to switch to Python 3 until a compelling reason shows up. 2.7 works great for what I do. The real story her…
To me py3 has far too few "killer features" to switch. I just keep using 2.6 for my stuff because a) it does the job and b) it's just a major inconvenience without any benefits to port everything to 3.
Re: Python 3 Wall of Shame
#67Interesting to see pymongo on that list.
What about other databases?
Edit: Mysql appears to be represented too
Re: Python 3 Wall of Shame
#68I am currently doing a similar sort of website, but trying to limit it to popular projects only. Also trying to group together a lot of the python 3 related articles and porting tips. My current research can be found here: http://goo.gl/SCImr Any corrections, or ideas for what can be on the site would be appreciated.
You're welcome to use content from https://bitbucket.org/pypy/compatibility. There is a growing list of dependencies at https://bitbucket.org/pypy/compatibility/wiki/depends.yaml.
Re: Python 3 Wall of Shame
#69Interesting to see pymongo on that list. What about other databases? Edit: Mysql appears to be represented too
SQLAlchemy is ported at least, don't know about all the low-level drivers though.