I can see the dilemma, but... > Maybe we should consider being more conservative, and > just having the > Unicode built-in type, the unicode() built-in function, > and the u"..." > notation, and then leaving all responsibility for > conversions up to > the user. Win32 and COM has been doing exactly this for the last couple of years. And it sucked. > On the other hand, *some* default conversion > seems needed, > because it seems draconian to make open(u"abcfile") fail with a > TypeError. For exactly this reason. The end result is that the first thing you ever do with a Unicode object is convert it to a string. > (While I want to see Python 1.6 expedited, I'd also not > like to see it > saddled with a system that proves to have been a mistake, or one > that's a maintenance burden. If forced to choose between > delaying and > getting it right, the latter wins.) Agreed. I thought this implementation stemmed from Guido's desire to do it this way in the 1.x family, and move towards Fredrik's proposal for Py3k. As a geneal comment: Im a little confused and dissapointed here. We are all bickering like children while our parents are away. All we are doing is creating a _huge_ pile of garbage for Guido to ignore when he returns. We are going to be presenting Guido with around 400 messages at my estimate. He can't possibly read them all. So the end result is that all the posturing and flapping going on here is for naught, and he is just going to do whatever he wants anyway - as he always has done, and as has worked so well for Python. Sheesh - we should all consider how we can be the most effective, not the most loud or aggressive! Mark.
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