Let's admit it. Once Django is Py3K-ready, all other projects will follow suit.
I would say, practical implementation of PEP-3333 is more important than Django.
Most Python frameworks are stuck because of WSGI vs Python 3 issue.
Python 3 Wall of Shame
51–60 of 80 posts
Re: Python 3 Wall of Shame
#52Let's admit it. Once Django is Py3K-ready, all other projects will follow suit.
If this is true, then there's a bit of a circular dependency Django is a pretty high-level project, though, with a lot of other dependencies of its own. I believe that the stated position of the Django core team is that there's no point in porting Django until some (all?) of the core dependencies are functional on Py3k. This, at least means wsgi and the database connectors, and possibly more. So I hope that the rest…
Right, Django wouldn't do much for me without MySQL-python.
Re: Python 3 Wall of Shame
#53Why isn't reportlab in the list?
Re: Python 3 Wall of Shame
#54I'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 here is how Python 3 appears to be a largely unwanted improvement, IMO.
Re: Python 3 Wall of Shame
#55Just picked one from the red list (pytz) and it looks like Py3.1 is supported...
Too many authors don't update their classifiers before uploading to PyPI. Plenty of things on that list are incorrect, but it's the package author's fault.
Re: Python 3 Wall of Shame
#56It will be interesting to see how Guido et al will judge the py3k transition-strategy in hindsight and whether they will repeat it or move back to a more traditional, incremental development model.
If you 'incrementally' include changes which are incompatible, you end up with many more compatibility barriers to keep track of.
"Oh wait, this machine has foo 1.5.2, not 1.5.6!!!"
Though a solution to this scenario is to avoid including too many libraries in the standard distribution in the first place, so that incompatible changes in those libraries don't affect the base.
This in turn means that big packages with lots of dependencies would need to say "you need fooliba-1.5.6, foolibb-4.3.2, etc" instead of just "you need foo-5.2", but other languages do this and they seem to manage it alright.
Re: Python 3 Wall of Shame
#57I'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…
maps/reduces returning iterators objects instead of a list. Having to call list() on anything I map is just a pain.
Re: Python 3 Wall of Shame
#58"Wall of Shame," sounds harsh. However I don't think it's entirely inappropriate. The premise is that it has been two years since py3k has been release and the community has little to show for it. One would think two whole years would be enough time to port a library. Especially if most of the fundamental challenges of doing so are matters of syntax (not in all cases I'm sure) and changing some names. OTOH, maybe the…
"Maybe py3k is viewed as "that bad," that no one wants to bother with it?" I don't think anyone's viewing it that way. A lot of people want to switch and many are, but there's the non-zero cost of porting and also the generally low demand. No one wants to spend 3 days of initial work on a port that no one currently wants, then tack on the continued maintenance of two branches (or a single code base that works with bo…
Actually, my LUG is also considering doing some sprints. I'm more inclined to join them after using py3 and wishing there was more support for it (and feeling bad about my own laziness in porting my own stuff). The sprints are a great idea and we're quite lucky to have such support!
Re: Python 3 Wall of Shame
#59It will be interesting to see how Guido et al will judge the py3k transition-strategy in hindsight and whether they will repeat it or move back to a more traditional, incremental development model.
If you 'incrementally' include changes which are incompatible, you end up with many more compatibility barriers to keep track of. "Oh wait, this machine has foo 1.5.2, not 1.5.6!!!" Though a solution to this scenario is to avoid including too many libraries in the standard distribution in the first place, so that incompatible changes in those libraries don't affect the base. This in turn means that big packages with…
Well, most other languages use the incremental approach, python is the outlier here.
I'm not saying one or the other is definitely better, just that I'm looking forward to the final judgement after this multi-year effort.
Re: Python 3 Wall of Shame
#60I 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.