[I18n-sig] sys.(set|get)_string_encoding in 1.6
Fri, 08 Sep 2000 13:56:08 +0200
Tamito KAJIYAMA wrote:
> "M.-A. Lemburg" <email@example.com> writes:
> | Tamito KAJIYAMA wrote:
> | >
> | > I found that sys.(get|set)defaultencoding() defined in the
> | > Unicode proposal version 1.6 were implemented with different
> | > names sys.(get|set)_string_encoding() in the 1.6 final release.
> | > Is this an intended change? If so, why is this incompatibility
> | > introduced?
> | These APIs were first introduced as experiment to the CVS tree
> | under the names you find in the 1.6 release. They were meant
> | to provide an easy way to experiment with different default
> | encodings.
> | After some discussions on python-dev the outcome
> | was to keep the APIs for use by site.py to set a locale
> | dependent default encoding.
> | This idea was then retracted some weeks later and replaced
> | with the now standard ASCII default encoding which you find
> | in both 1.6 and 2.0.
> I see.
> | So to answer your question: the sys APIs in 1.6 are to be
> | considered undocumented features and should *not* be used.
> Then, is there no way to set/get the default encoding in 1.6?
No, there's no offical way to do this.
You could of course use the undocumented APIs, but you should
be careful not to create any Unicode objects *before* setting
the default in e.g. site.py. The same applies to 2.0.
The reason is that Unicode objects cache their default
encoded string version but don't store the encoding this
string uses. This could lead to the cached version using
a different encoding than the current default encoding.
In any case I'd suggest not relying on the default encoding,
but instead using explicit calls to .encode() and unicode()
to apply the proper conversions -- this is always safe,
uses less magic and is also more portable across Python
Python Pages: http://www.lemburg.com/python/