On Fri, Feb 10, 2012 at 5:25 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Thu, Feb 9, 2012 at 12:16 PM, Giampaolo Rodolà <g.rodola@gmail.com> wrote:
I bet a lot of people don't want to upgrade for another reason: unicode. The impression I got is that python 3 forces the user to use and *understand* unicode and a lot of people simply don't want to deal with that. In python 2 there was no such a strong imposition. Python 2 string type acting both as bytes and as text was certainly ambiguos and "impure" on different levels and changing that was definitively a win in terms of purity and correctness. I bet most advanced users are happy with this change. On the other hand, Python 2 average user was free to ignore that distinction even if that meant having subtle bugs hidden somewhere in his/her code. I think this aspect shouldn't be underestimated.
Isn't that more accurate for framework writers, rather than for "average" users? How often do average users have to address encoding/decoding in Python 3?
The problem for average users *right now* is that many of the Unicode handling tools that were written for the blurry "is-it-bytes-or-is-it-text?" 2.x 8-bit str type haven't been ported to 3.x yet. That's currently happening, and the folks doing it are the ones who really have to make the adjustment, and figure out what they can deal with on behalf of their users and what they need to expose (if anything). The idea with Python 3 unicode is to have errors happen at (or at least close to) the point where the code is doing something wrong, unlike the Python 2 implicit conversion model, where either data gets silently corrupted, or you get a Unicode error far from the location that introduced the problem. I actually find it somewhat amusing when people say that python-dev isn't focusing on users enough because of the Python 3 transition or the Windows installer problems. What they *actually* seem to be complaining about is that python-dev isn't focused entirely on users that are native English speakers using an expensive proprietary OS. And that's a valid observation - most of us are here because we like Python and primarily want to make it better for the environments where *we* use it, which is mostly a combination of Linux and Mac users, a few other POSIX based platforms and a small minority of Windows developers. Given the contrariness of Windows as a target platform, the time of those developers is mostly spent on making it keep working, and bringing it up to feature parity with the POSIX version, so cleaning up the installation process falls to the wayside. (And, for all the cries of, "Python should be better supported on Windows!", we just don't see many Windows devs signing up to help - since I consider developing for Windows it's own special kind of hell that I'm happy to never have to do again, it doesn't actually surprise me there's a shortage of people willing to do it as a hobby) In terms of actually *fixing it*, the PSF doesn't generally solicit grant proposals, it reviews (and potentially accepts) them. If anyone is serious about getting something done for 3.3, then *write and submit a grant proposal* to the PSF board with the goal of either finalising the Python launcher for Windows, or else just closing out various improvements to the current installer that are already on the issue tracker (e.g. version numbers in the shortcut names, an option to modify the system PATH). Even without going all the way to a grant proposal, go find those tracker items I mentioned and see if there's anything you can do to help folks like Martin von Loewis, Brian Curtin and Terry Reedy close them out. In the meantime, if the python.org packages for Windows aren't up to scratch (and they aren't in many ways), *use the commercially backed ones* (or one of the other sumo distributions that are out there). Don't tell your students to grab the raw installers directly from python.org, redirect them to the free rebuilds from ActiveState or Enthought, or go all out and get them to install something like Python(X, Y). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia