> Since this is a Mac-specific thing (and Classic-originated at
> that), I think you can be pretty sure that any non-ASCII value
> is to be interpreted according to the Macintosh character set,
> if it's meant to be a character at all.
Please understand that there is no such thing as "the Macintos
currently, testing for "x in xrange(y)" is an O(n) operation.
since xrange objects (which would become range in py3k) are not real lists,
there's no reason that __contains__ be an O(n). it can easily be made into
an O(1) operation. here's a demo code (it should be trivial to implement
this in CPyt
Do we really need another way to spell a <= x < b? Have you got a
real-world use case in mind for the version with step > 1?
I'm at most lukewarm; I'd be willing to look at a patch to the C code
in the py3k-struni branch, plus unit tests though.
--Guido
On 7/28/07, tomer filiba <[EMAIL PROTECTED
Guido van Rossum wrote:
> Do we really need another way to spell a <= x < b?
FWIW, I'd say yes; I sometimes find it a bit difficult to remember
how the operator should be placed, there are several possible ways
of making a mistake, eg;
a > x < b
a < x > b
a < x < b
a > x > b
Now, the
On Jul 20, 1:52 pm, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> I discovered what appears to be a thread-unsafety inuuid.py. This is
> in the trunk as well as in 3.x; I'm using the trunk here for easy
> reference. There's some code around like 395:
>
> import ctypes, ctypes.util
> _buf
On 7/27/07, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> On 7/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 7/26/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> > > On 7/26/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > (Personally
> > > > I'd like to use strings for the keys sin
I just submitted a patch to fix test_urllib2 and test_cookielib. In the
process of fixing them I came across something that looks like an
inconsistency in the base64 module.
Right now the base64 module uses bytes for everything. That is,
a value passed to b64encode() must be bytes, and the
base64
Joe Gregorio wrote:
> Shouldn't it operate more like expat, with the stuff to be
> encoded is bytes and the encoded form is a string?
> It seems more natural if the encoded value is a string since
> base64 encoding is a way of encoding data
> so that it fits in US-ASCII.
Py3k strings are unicode,
> It seems more natural if the encoded value is a string since
> base64 encoding is a way of encoding data
> so that it fits in US-ASCII.
There have been long debates about this specific question in
the past. The point that proponents of "base64 encoding should
yield strings" miss is that US-ASCII
Johan Dahlin schrieb:
> Guido van Rossum wrote:
>> Do we really need another way to spell a <= x < b?
>
> FWIW, I'd say yes; I sometimes find it a bit difficult to remember
> how the operator should be placed, there are several possible ways
> of making a mistake, eg;
>
>a > x < b
>a < x
10 matches
Mail list logo
