On Wed, Dec 4, 2013 at 11:15 AM, Hans-Peter Jansen wrote:
> Given the amount of special unicode handling code, that is necessary to keep
> Python 2 happy, makes proceeding with it no real fun on a longer term..
>
> And the biggest proponent for hacking in Python IS the fun part of it. Then
> produ
Hi Chris,
On Mittwoch, 4. Dezember 2013 10:20:31 Chris Angelico wrote:
> On Wed, Dec 4, 2013 at 9:32 AM, Hans-Peter Jansen wrote:
> > I'm experiencing strange behavior with attached code, that differs
> > depending on sys.setdefaultencoding being set or not. If it is set, t
On Wed, Dec 4, 2013 at 9:32 AM, Hans-Peter Jansen wrote:
> I'm experiencing strange behavior with attached code, that differs depending
> on sys.setdefaultencoding being set or not. If it is set, the code works as
> expected, if not - what should be the usual case - the code fails w
Hi,
I'm experiencing strange behavior with attached code, that differs depending
on sys.setdefaultencoding being set or not. If it is set, the code works as
expected, if not - what should be the usual case - the code fails with some
non-sensible traceback.
I tried to boil it down
> Is there a way to allow the process to specify that unicode-->str should
> use 'utf8' rather than 'ascii' in all non-specific cases?
No. Things might break if you change the default encoding to anything
but ASCII, and more so if you do that "at runtime". For example,
dictionaries with Unicode ke
Can someone explain the rationale of making the default encoding a sitewide
setting?
I could live with the the default being set on a per process basis, but it
baffles me why even that possibility is taken away as site.py removes
sys.setdefaultencoding.
Is there a way to allow the process to
