[Python-Dev] Internationalization Toolkit

[M.-A. Lemburg]

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/