Reliably getting/setting the (current) encoding name?
mwh at python.net
Fri Jan 31 19:15:57 CET 2003
"Mike C. Fletcher" <mcfletch at rogers.com> writes:
> Michael Hudson wrote:
> >"Mike C. Fletcher" <mcfletch at rogers.com> writes:
> >>The codecs module doesn't appear to have a "get default codec name"
> >>function. So I'm asking the question:
> >> How does one reliably get the currently-active default codec name
> >> (i.e. the one that reflects the currently-set locale) as suitable
> >> for use with uncode.encode( ... )?
> >I don't know the answer to this one, I'm afraid.
> >>> import sys
> >>> sys.getdefaultencoding()
> (Alex mentioned it in his post)
But that doesn't change to reflect the locale, which I thought was the
point of what you asked.
> >Here I'd say: don't add conversion code "all over the joint", add it
> >"at the edges", i.e. where the unicode strings get into your library.
> Yes, I'm not particularly infatuated with the idea of multi-line
> conversion hacks all over my libraries :) , the difficulty with using
> the "edges" is that the (GUI) library is constantly interacting with
> various wxTextCtrl objects, which, in the Unicode builds of wxPython
> are suddenly returning unicode instead of str objects, which means the
> Unicode strings are arriving all through the library, sometimes being
> directed at the object model, sometimes at status messages, sometimes
> to the logging system etc.
That did occur to me as a possible problem. Did we mention converting
your app to all-unicode-all-the-time? Oh yes, I think you did. Try
it: it might not be as hard as you think. I was surprised how easy it
was to convert pyrepl.
> At the moment, I'm going to go down the path to evil and requiring
> the application to set a useful default encoding using the hack Alex
> pointed out.
Don't come running to us when, etc. :-)
The bottom tier is what a certain class of wanker would call
"business objects" ... -- Greg Ward, 9 Dec 1999
More information about the Python-list