Mark Hammond wrote: > > > Mark Hammond wrote: > > > Having a fixed, default encoding may make life slightly > > more difficult > > > when you want to work primarily in a different encoding, > > but at least > > > your system is predictable and reliable. > > > > I think the discussion on this is getting a little too hot. > > Really - I see it as moving to a rational consensus that doesnt > support the proposal in this regard. I see no heat in it at all. Im > sorry if you saw my post or any of the followups as "emotional", but I > certainly not getting passionate about this. I dont see any of this > as affecting me personally. I believe that I can replace my Unicode > implementation with this either way we go. Just because a we are > trying to get it right doesnt mean we are getting heated. Naa... with "heated" I meant the "HP wants this, HP wants that" side of things. We'll just have to wait for their answer on this one. > > The point > > is simply that the option of changing the per-thread default > encoding > > is there. You are not required to use it and if you do you are on > > your own when something breaks. > > Hrm - Im having serious trouble following your logic here. If make > _any_ assumptions about a default encoding, I am in danger of > breaking. I may not choose to change the default, but as soon as > _anyone_ does, unrelated code may break. > > I agree that I will be "on my own", but I wont necessarily have been > the one that changed it :-( Sure there are some very subtile dangers in setting the default to anything other than the default ;-) For some this risk may be worthwhile taking, for others not. In fact, in large projects I would never take such a risk... I'm sure we can get this message across to them. > The only answer I can see is, as you suggest, to ignore the fact that > there is _any_ default. Always specify the encoding. But obviously > this is not good enough for HP: > > > Think of it as a HP specific feature... perhaps I should wrap the > code > > in #ifdefs and leave it undocumented. > > That would work - just ensure that no standard Python has those > #ifdefs turned on :-) I would be sorely dissapointed if the fact that > HP are throwing money for this means they get every whim implemented > in the core language. Imagine the outcry if it were instead MS' > money, and you were attempting to put an MS spin on all this. > > Are you writing a module for HP, or writing a module for Python that > HP are assisting by providing some funding? Clear difference. IMO, > it must also be seen that there is a clear difference. > > Maybe Im missing something. Can you explain why it is good enough > everyone else to be required to assume there is no default encoding, > but HP get their thread specific global? Are their requirements > greater than anyone elses? Is everyone else not as important? What > would you, as a consultant, recommend to people who arent HP, but have > a similar requirement? It would seem obvious to me that HPs > requirement can be met in "pure Python", thereby keeping this out of > the core all together... Again, all I can try is convince them of not really needing settable default encodings. <IMO> Since this is the first time a Python Consortium member is pushing development, I think we can learn a lot here. For one, it should be clear that money doesn't buy everything, OTOH, we cannot put the whole thing at risk just because of some minor disagreement that cannot be solved between the parties. The standard solution for the latter should be a customized Python interpreter. </IMO> -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 49 days left 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