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
Tim Peters wrote:
> Changing the user-visible API is a hard egg to
> swallow, and it's unfortunate that the Python code used a dict to hold
> "flags" to begin with. The dict doesn't just record whether an
> exception has occurred, it also counts how many times the exception
> occurred. It's poss
Lisandro Dalcin wrote:
On 7/18/06, Tim Peters <[EMAIL PROTECTED]> wrote:
[Raymond Hettinger]
...
If the current approach gets in their way, the C implementers should feel free to
make an alternate design choice.
I expect they will, eventually. Conve
On 7/18/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Raymond Hettinger]
> > ...
> > If the current approach gets in their way, the C implementers should feel
> > free to
> > make an alternate design choice.
>
> I expect they will, eventually. Converting this to C is a big job,
> and at the NFS sp
Aahz wrote:
On Tue, Jul 18, 2006, Raymond Hettinger wrote:
P.S. The dictionary approach to context objects should likely be
abandoned for the C version. If the API has to change a bit, then so
be it.
Why do you say that? The rest I agree with; seems to me that making
[Raymond Hettinger]
> ...
> If the current approach gets in their way, the C implementers should feel
> free to
> make an alternate design choice.
I expect they will, eventually. Converting this to C is a big job,
and at the NFS sprint we settled on an "incremental" strategy allowing
most of the
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
On Tue, Jul 18, 2006, Raymond Hettinger wrote:
>
> P.S. The dictionary approach to context objects should likely be
> abandoned for the C version. If the API has to change a bit, then so
> be it.
Why do you say that? The rest I agree with; seems to me that making a
small wrapper for dict access
I briefly had a chance to look at some of the work being done on a C
implementation of decimal, and it looks like the approach is following
the Python version too literally.
Ideally, it should be written as if Python were not involved and
afterwards add the appropriate method wrappers. Context
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 7/17/06, Boris Borcic <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > You must be misunderstanding.
>
> I don't think so. You appeared to say that the language changes too much
> because
> everyone wants different changes - that accumulate. I suggested a mechanism
> allowing people to
On 7/18/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> I think this was Greg's point. Talking about C++ and super() is
> nonsensical.
If you're talking pure C++, yes. But I was talking about programming
system built on top of C++ implementing cooperating multitasking.
As I am fond of repea
On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > In the world where cooperative multiple inheritance
> > originated (C++), this would be a static error.
>
> I wasn't aware that C++ had anything resembling super().
> Is it a recent addition to the language?
I don't kn
On 7/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> C++ originally specified multiple inheritance, but it wasn't "cooperative" in
> the sense that super is. In Lisp, though, where cooperative method dispatch
> originated, call-next-method does basically the same thing in the case where
> th
"Boris Borcic" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Allowing different language variants connected by reversible transforms
> means
> one need not change any user's understood meaning of any block of code.
> The user
> stipulates the language variant she likes and the s
On Tue, 18 Jul 2006 09:24:57 -0400, Jean-Paul Calderone <[EMAIL PROTECTED]>
wrote:
>On Tue, 18 Jul 2006 09:10:11 -0400, Scott Dial <[EMAIL PROTECTED]> wrote:
>>Greg Ewing wrote:
>>> Guido van Rossum wrote:
In the world where cooperative multiple inheritance
originated (C++), this would
On Tue, 18 Jul 2006 09:10:11 -0400, Scott Dial <[EMAIL PROTECTED]> wrote:
>Greg Ewing wrote:
>> Guido van Rossum wrote:
>>> In the world where cooperative multiple inheritance
>>> originated (C++), this would be a static error.
>>
>> I wasn't aware that C++ had anything resembling super().
>> Is it
Greg Ewing wrote:
> Guido van Rossum wrote:
>> In the world where cooperative multiple inheritance
>> originated (C++), this would be a static error.
>
> I wasn't aware that C++ had anything resembling super().
> Is it a recent addition to the language?
>
It is much more explicit, but you call t
Please. Just end this discussion. It ain't gonna happen.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart
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.
>
>
Josiah Carlson wrote:
> Boris Borcic <[EMAIL PROTECTED]> wrote:
>> Of course, and that's why in my initial post I was talking of transparent
>> reversible transforms and central control of "styles" through the standard.
>> Means not to fall into the trap you describe. Or else I would have asked fo
Guido van Rossum wrote:
> In the world where cooperative multiple inheritance
> originated (C++), this would be a static error.
I wasn't aware that C++ had anything resembling super().
Is it a recent addition to the language?
--
Greg
___
Python-Dev mail
34 matches
Mail list logo
