This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients belopolsky, eric.araujo, ezio.melotti, jcea, lemburg, sdaoden, vstinner
Date 2011-02-24.16:01:50
SpamBayes Score 8.91827e-08
Marked as misclassified No
Message-id <4D6680ED.5090305@egenix.com>
In-reply-to <AANLkTi=kY1s-ScxjhKSAB9HWyTCdEGJxnMVuBYbso9X2@mail.gmail.com>
Content
Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
> 
> On Thu, Feb 24, 2011 at 10:30 AM, Ezio Melotti <report@bugs.python.org> wrote:
> ..
>> See also discussion on #5902.
> 
> Mark has closed #5902 and indeed the discussion of how to efficiently
> normalize encoding names (without changing what is accepted) is beyond
> the scope of that or the current issue.  Can someone open a separate
> issue to see if we can improve the current situation?  I don't think
> having three slightly different normalize functions is optimal.  See
> msg129248.

Please see my reply on this ticket: those three functions have
different application areas.

On this ticker, we're discussing just one application area: that
of the builtin short cuts.

To have more encoding name variants benefit from the optimization,
we might want to enhance that particular normalization function
to avoid having to compare against "utf8" and "utf-8" in the
encode/decode functions.
History
Date User Action Args
2011-02-24 16:01:52lemburgsetrecipients: + lemburg, jcea, belopolsky, vstinner, ezio.melotti, eric.araujo, sdaoden
2011-02-24 16:01:50lemburglinkissue11303 messages
2011-02-24 16:01:50lemburgcreate