Default Encoding

Changing the default encoding in site.py from the Python default is asking for
trouble. This can break or change the behaviour of programs in subtle ways. I
think Ubuntu developers should make the case to the Python upstream that they
should change the default encoding to UTF-8, but should not do so for Ubuntu
until Python upstream does so.

It was my understanding that the whole point of having the default encoding
*only* settable inside site.py was to stop programmers relying on any default
encoding for their scripts?

Has this backfired on them and resulted in a total assumption that it's C? I
would be oh-so-surprised :o)

Can we petition them to leave sys.setdefaultencoding() alone for any application
to play with too?

So what you really want is to have a possibility to play with it? I.e. depending
on an environment variable PYTHON_DEFAULT_ENCODING, set it UTF8? I don't like to
change the default for Ubuntu only. OTOH it's a config file to play with ...

default encoding is still 'ascii' in dapper's python2.4 package.
is this going to get changed, has anyone talked to upstream?
there is some discussion about this on these blogs:

http://blog.ianbicking.org/illusive-setdefaultencoding.html
http://faassen.n--tree.net/blog/view/weblog/2005/08/02/0

perhaps this should be discussed on ubuntu-devel?

From reading these weblog articles, it is clear that the only sane way forward
is if Python upstream changes the default encoding.

Interestingly, Frederik Lundh, a core python developer, says that the hook to
set the default encoding should have been removed before a final release.

Have there been any developments with this bug? It's been NeedInfo for quite a while.

Thanks

Yes, python upstream probably won't change default encoding before python 3.0.

Drop postrm, patch postinst to remove existing symlink, install rulesfile in correct place.

meh -EBADBUG for the attachment...

At least a few folks seem to agree this is a bug. Changing to confirmed.

Interesting. I felt it was pretty much agreed that Ubuntu should not change this until upstream Python changes.

To change this in Ubuntu and not for Python environments in general will cause problems, such as Python code written on an Ubuntu system not working correctly when used elsewhere, and thus Ubuntu being an unsuitable platform for testing Python code.

This goes against the goal of making Ubuntu a preferred platform for Python development.

I understand the last statement, but i'd like an advice :

When i get input in python from my utf-8 terminal, if a global-like setting (like site.py) is telling me that input is utf-8, from what/where source could I know input is coming as utf-8 ?

I think I should inspect the locale, the deduce the charset, and then "something" globally for my app to know that every unicode() call should translate from utf-8. Is that right ?

If tha'ts the case, knowing that all my ubuntu system is utf-8 aware and configured for, i thought it was "easyer" but consistant too, for site.py to detect this and set it globally for python.

my 2 cents : in site.py, i didn't change the default encoding (let it to us-ascii), but I activated the "if 0:" lines, which find the locale and set the defaut encoding from the locale charset. In this case, when the locale is unset or its charset unknow, defaut goes back to us-ascii, and I feel this very consistant.

What's you opinion ? Should I point at elsewhere to find an already discussed topic ?

reassign the report for python; won't be changed for any released python version. it's likely to be changed by upstream in py3k.

Seems the consensus is that upstream should be the one to determine if it's beneficial to implement this change; mark as invalid?

> Seems the consensus is that upstream should be the one to determine if it's beneficial to implement this change; mark as invalid?

will change when python (>= 3) is the default.

fixed in python3-defaults, won't fix for python-defaults