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
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 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 ide
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
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 before").
That still wouldn't work with Python 1.5.2, as that version d
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
t
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
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 string methods suggests to me that
the logging package attempts to work wi
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 i
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 ha
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
>
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:
> 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
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 back
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.
__
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"
> >
> > u"INFO".lower() == "info" (at least in the Turkish locale).
> >
> > Is that guaranteed, at le
On Tue, Jul 18, 2006 at 10:53:23AM -0700, Guido van Rossum wrote:
> And u"info".upper()?
Yepp, that shows the right thing (at least in the several locales I tested,
Turkish included).
It's along the lines of u"INFO".lower() I was proposing in my second post :-)
Misa
_
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"
> >>
> >> u"INFO".lower() == "info" (at least in th
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"
>>>
>>> u"INFO".lower() == "info" (at least in the Turkish locale).
>>>
>>> Is that
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"
>>
>> u"INFO".lower() == "info" (at least in the Turkish locale).
>>
>> Is that guaranteed, at least for now (for
Mihai Ibanescu wrote:
> To follow up on my own email: it looks like, even though in some locale
> "INFO".lower() != "info"
>
> u"INFO".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; unico
And u"info".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
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
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:
> >
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1524081
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=detail&aid=1524081&group_id=5470&atid=105470
>
> I am willing to try and patch the problem, but I'd like to discuss my ideas
> first.
>
>
Hi,
This is reported on sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=1524081&group_id=5470&atid=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,
initializin
26 matches
Mail list logo
