On Thu, Jul 20, 2006 at 05:09:38AM -0500, [EMAIL PROTECTED] wrote:
Misa Good point. Does the attached patch look reasonable?
...
Misa -self.when = string.upper(when)
Misa +self.when = unicode(when).upper()
...
The use of the string module instead of
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
On Thu, Jul 20, 2006 at 06:08:05PM +0200, Martin v. Löwis wrote:
Mihai Ibanescu wrote:
It's up to Vinay to decide if we want to drop support for 1.5.2 in the
module
included in newer pythons, or the attached patch would make it work for
1.5.2
as well (as in it's not more broken than
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.
Mihai Ibanescu wrote:
Yes, as I said, it won't be more broken than before applying the patch (my
first patch was breaking 1.5.2 completely).
Ah, I didn't notice that it deals with unicode() not being a builtin.
That's fine then.
Regards,
Martin
___
On 7/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Thu, Jul 20, 2006 at 11:39:27AM -0400, Jim Jewett wrote:
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
On Tue, Jul 18, 2006 at 02:55:56PM -0400, Fred L. Drake, Jr. wrote:
On Tuesday 18 July 2006 14:52, Mihai Ibanescu wrote:
Unicode might be a perfectly acceptable suggestion for others too.
Are we still supporting builds that don't include Unicode? If so, that needs
to be considered in a
On Mon, Jul 17, 2006 at 03:39:55PM -0400, Mihai Ibanescu wrote:
Hi,
This is reported on sourceforge:
http://sourceforge.net/tracker/index.php?func=detailaid=1524081group_id=5470atid=105470
I am willing to try and patch the problem, but I'd like to discuss my ideas
first.
The basic
Alternatively, does info.upper() == INFO everywhere?
On 7/18/06, Mihai Ibanescu [EMAIL PROTECTED] wrote:
On Mon, Jul 17, 2006 at 03:39:55PM -0400, Mihai Ibanescu wrote:
Hi,
This is reported on sourceforge:
On Tue, Jul 18, 2006 at 10:19:54AM -0700, Guido van Rossum wrote:
Alternatively, does info.upper() == INFO everywhere?
Not in the Turkish locale :-(
# begin /tmp/foo.py
import locale
locale.setlocale(locale.LC_ALL, '')
print info.upper()
print info.upper() == INFO
# end /tmp/foo.py
And uinfo.upper()?
On 7/18/06, Mihai Ibanescu [EMAIL PROTECTED] wrote:
On Tue, Jul 18, 2006 at 10:19:54AM -0700, Guido van Rossum wrote:
Alternatively, does info.upper() == INFO everywhere?
Not in the Turkish locale :-(
# begin /tmp/foo.py
import locale
locale.setlocale(locale.LC_ALL,
Mihai Ibanescu wrote:
To follow up on my own email: it looks like, even though in some locale
INFO.lower() != info
uINFO.lower() == info (at least in the Turkish locale).
Is that guaranteed, at least for now (for the current versions of python)?
It's guaranteed for now; unicode.lower is
On Jul 18, 2006, at 1:54 PM, Martin v. Löwis wrote:
Mihai Ibanescu wrote:
To follow up on my own email: it looks like, even though in some
locale
INFO.lower() != info
uINFO.lower() == info (at least in the Turkish locale).
Is that guaranteed, at least for now (for the current versions
James Y Knight wrote:
On Jul 18, 2006, at 1:54 PM, Martin v. Löwis wrote:
Mihai Ibanescu wrote:
To follow up on my own email: it looks like, even though in some
locale
INFO.lower() != info
uINFO.lower() == info (at least in the Turkish locale).
Is that guaranteed, at least for now
On 7/18/06, James Y Knight [EMAIL PROTECTED] wrote:
On Jul 18, 2006, at 1:54 PM, Martin v. Löwis wrote:
Mihai Ibanescu wrote:
To follow up on my own email: it looks like, even though in some
locale
INFO.lower() != info
uINFO.lower() == info (at least in the Turkish locale).
Is
On Tue, Jul 18, 2006 at 10:53:23AM -0700, Guido van Rossum wrote:
And uinfo.upper()?
Yepp, that shows the right thing (at least in the several locales I tested,
Turkish included).
It's along the lines of uINFO.lower() I was proposing in my second post :-)
Misa
On Tue, Jul 18, 2006 at 07:54:28PM +0200, Martin v. Löwis wrote:
Mihai Ibanescu wrote:
To follow up on my own email: it looks like, even though in some locale
INFO.lower() != info
uINFO.lower() == info (at least in the Turkish locale).
Is that guaranteed, at least for now (for the
On Tuesday 18 July 2006 14:52, Mihai Ibanescu wrote:
Unicode might be a perfectly acceptable suggestion for others too.
Are we still supporting builds that don't include Unicode? If so, that needs
to be considered in a patch as well.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
James Y Knight wrote:
That seems backwards of how it should be ideally: the byte-string upper
and lower should always do ascii uppering-and-lowering, and the unicode
ones should do it according to locale. Perhaps that can be cleaned up in
py3k?
Cleaned-up, yes. But it is currently not
M.-A. Lemburg wrote:
The Unicode database OTOH *defines* the upper/lower case mapping in
a locale independent way, so the mappings are guaranteed
to always produce the same results on all platforms.
Actually, that isn't the full truth; see UAX#21, which is now official
part of Unicode 4. It
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
The Unicode database OTOH *defines* the upper/lower case mapping in
a locale independent way, so the mappings are guaranteed
to always produce the same results on all platforms.
Actually, that isn't the full truth; see UAX#21, which is now
M.-A. Lemburg wrote:
Right. In fact, some case mappings are not available in the Unicode
database, since that only contains mappings which don't increase or
decrease the length of the Unicode string. A typical example is the
German u'ß'. u'ß'.upper() would have to give u'SS', but instead
James Y Knight wrote:
That seems backwards of how it should be ideally: the byte-string
upper and lower should always do ascii uppering-and-lowering, and the
unicode ones should do it according to locale. Perhaps that can be
cleaned up in py3k?
I would expect bytes objects not to have
Hi,
This is reported on sourceforge:
http://sourceforge.net/tracker/index.php?func=detailaid=1524081group_id=5470atid=105470
I am willing to try and patch the problem, but I'd like to discuss my ideas
first.
The basic problem is that, in some locale, INFO.lower() != info. So,
initializing a
24 matches
Mail list logo
