Jack Jansen wrote: > > I'm getting pretty depressed at the way Python development is > proceeding at the moment. You're not the only one. > I spent all evening tonight on what seemed > to be an almost trivial task: fixing the default unicode conversion on > the Mac. All the machinery is there, the MacOS API has some nice > conversion routines so I thought it'd be a question of putting in a > few hooks and be done, but that turned out not to be so. > > The first problem (for which I can't blame the Python community, I > guess:-) is that the names mac_roman and such are not official IANA > names for the Mac encodings. Actually, it turns out there _are_ no > official names, so the Mac APIs to turn encodings into names work > wonderful for things including all ISO encodings, windows encodings, > etc, but not for the native mac encodings. Sigh. Okay, we do this > ourselves. What exactly is your problem here ? The Python codec engine does know about the Mac encodings and even provides mapping tables for them. > Then I spent an hour recompiling Python because this *&^^$%&*^%$ > setdefaultencoding didn't show up in sys for no conceivable reason. It > turns out it is *deleted* in site.py after using it once. A comment in > sysmodule.c would have been rather nice here... There are lots of comments about it in site.py. sys.setdefaultencoding() is meant to be used *only* in site.py-- that's why it gets removed after having made the final decision on the default encoding. > And then I found out that locale uses only environment variables to > obtain all the basic encoding info in the first place, so that also > has to be fixed up seriously. That's not because we don't like Macs, it's simply because the people hacking on the code don't have Macs around to hack something up. But we did politely ask for someone with Mac-knowledge to add the needed support to locale.py. I did the Unix stuff, Fredrik added Windows support and we hoped that Just or you would add Mac support. Note that site.py will simply choose ASCII as default encoding in case it can't figure out what the current default encoding on the platform is -- there's no breakage there... Since all this support is written in Python there should be really no problem adding new hooks to it. > So many things are changing at the moment, and there seems to be so > little thought of any platform that isn't linux or windows, that I > think Python's portability to minority platforms is being seriously > threatened. And at least I follow closely what is happening, I really > don't want to think of the poor people who do BeOS or WinCE or Palm > Python. Or even some of the lesser-used Unix ports. > > I'm fed up, I'll continue hacking tomorrow, if I don't have to spend > yet another evening trying to get Python to compile again:-( -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4