On Thu, Oct 2, 2008 at 11:11 AM, Fred Drake firstname.lastname@example.org wrote:
That doesn't mean it's not scary when thinking about writing portable code in this environment. That's not entirely new, but the fact that so much of these details are being addressed so late in the release cycle *should* give cause for concern, especially to those of use who are still a long way from stepping up to current versions.
I had always expected that issues like these would crop up fairly late in the Py3k development cycle -- the first two years were completely filled with discussions about language changes, and then their implementation. Library stuff (and this *is* library stuff, even if it's pretty fundamental) necessarily had to come later, once we had a more-or-less usable version of the language.
FWIW, I don't expect any of the other release blockers to be quite this invasive -- and this one is actually not all that invasive, since most system calls *already* supported bytes alongside with text strings. There are only two C-level changes: the addition of getcwdb() (and the removal of getcwdu()), and the change in behavior for listdir() with a text string argument (skipping undecodable filenames rather than returning raw bytes). There was a one-line change in io.py to make the built-in open() function (which is really an alias for io.open()) accept bytes, and then a bunch of changes to posixpath.py, glob.py and fnmatch.py to support bytes.
It's really not very invasive, and not much changes -- the changes are mostly in our minds, as we now have all learned about the issues and the differences between platforms, and know what to tell people to do about them. *That* is the major change, not the few code changes.