A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2006-July/067579.html below:

[Python-Dev] logging module broken because of locale

[Python-Dev] logging module broken because of localemihaiibanescu at yahoo.com mihaiibanescu at yahoo.com
Thu Jul 20 18:19:02 CEST 2006
On Thu, Jul 20, 2006 at 11:39:27AM -0400, Jim Jewett wrote:
> Mihai,
> 
> It does make sense to document this limit for people writing
> subclasses, or using a Turkic codeset.  I'm not sure that logging is
> the right place to document it, and I don't think changing the base
> classes is a good idea.
> 
> TimedRotatingFileHandler and HTTPHandler restrict their input to a
> tiny subset of ASCII; anything that would be handled differently after
> these changes will already raise a ValueError unless you subclass.
> 
> Even SysLogHandler.emit doesn't actually print the string; it is only
> used as a lookup key for a dictionary whose keys are all lower-case
> ASCII.  In theory, you could monkey-patch that dictionary to add
> additional values, but then you might as well subclass to do the right
> thing with your new keys.  (It *might* make sense to change the base
> function and dictionary to accept unicode, including undotted-i
> synonyms.)

Hi Jim,

I am afraid you lost me.

My initial approach was to compute the values of the dictionary based on the
current locale - and that doesn't work.

The issue is not that the dictionary doesn't accept unicode, it's that there's
no reliable way to do lookups in it. If you could sketch an example of what
you had in mind with the monkey-patching, please do so, since I don't think I
grasped the idea.

Misa
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4