On 9/28/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> |
> | Well, if we wanted "x" and b"x" to compare unequal instead of raising
> | an exception, we could just define it that way (it was that way until
> | just befo
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|
| Well, if we wanted "x" and b"x" to compare unequal instead of raising
| an exception, we could just define it that way (it was that way until
| just before 3.0a1). But we're explicitly defining it to raise a
| Type
Adam Hupp wrote:
> Would it make sense to have dict ignore TypeError on lookups?
> Alternatively, the byte/str comparison could throw a specific subclass
> of TypeError that dict ignored e.g. IncompatibleComparisonError.
Presumably the reason for making strings and bytes uncomparable
in the first
Jim Jewett wrote:
> If code clears an existing dict rather than creating a new one, then
> that specific dict is probably a communication channel, and the API
> should specify whether it takes bytes or characters.
This suggests it might be simpler to have normal dicts
refuse to accept bytes at all
> msvcrt ships with the operating system - I'd call that a conforming
> implementation.
Yes, but it's not part of the operating system interface; Microsoft
documents it as "for future use only by system-level components".
> I still regard handling argv as anything other the raw bytes that come
>
Jim Jewett wrote:
> On 9/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>
>> The question is whether it's worth the effort to raise TypeError when
>> the *potential* exists that a certain hash sequence *could* raise this
>> TypeError.
>>
>
> Bugs depending on the hash sequence are exa
On 9/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The question is whether it's worth the effort to raise TypeError when
> the *potential* exists that a certain hash sequence *could* raise this
> TypeError.
Bugs depending on the hash sequence are exactly the sort of thing that
doesn't get
On 26/09/2007, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > The array module is built in, so it's
> > written in C - what needs to be exposed to qualify as a "C API"?
>
> I think he's referring to the fact that there is no
> public array.h header file provided that lays out the
> C
On 9/28/07, Adam Hupp <[EMAIL PROTECTED]> wrote:
> On 9/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Well, maybe this is a good enough argument to give up. If the best we
> > can say is that having a bytes and a str as keys *may* cause a
> > TypeError on lookups, I'm not sure it is worth
On 9/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Well, maybe this is a good enough argument to give up. If the best we
> can say is that having a bytes and a str as keys *may* cause a
> TypeError on lookups, I'm not sure it is worth it to try to raise the
> probability that it'll actually
On 9/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Well, maybe this is a good enough argument to give up.
Not quite yet... I still see two potential solutions, depending on
whether or not the exclusion is sticky. Details below.
=
If the exclusion is sticky, then add (implicit) fl
Well, maybe this is a good enough argument to give up. If the best we
can say is that having a bytes and a str as keys *may* cause a
TypeError on lookups, I'm not sure it is worth it to try to raise the
probability that it'll actually be raised...
--Guido
On 9/28/07, Jim Jewett <[EMAIL PROTECTED]
On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/27/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Should a TypeError be raised as soon as you try to put a bytes and a
> > string in the same dict, even if they don't happen to hash equal?
> Good idea, if you can figure out a way to im
On Friday 28 September 2007 18:44:43 you wrote:
> > GMP doesn't have a concept of a non-complex structure. It always
> > allocates memory. (...)
I don't know GMP internals. I thaught that GMP uses an hack for small
integers.
> > Also, removing python's caching of integers < 100 as you did in thi
On 9/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
>
> On Sep 27, 2007, at 10:29 PM, Victor Stinner wrote:
>
> > Hi,
> >
> > I read some days ago a discussion about GMP (license). I wanted to
> > know if GMP
> > is really better than current Python int/long implementation. So I
> > wrote a
> > p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Another day, another update. Latest code: http://umass.glexia.net/mpf.tar.bz2
There's been a couple minor changes externally:
a) MPF() now takes a float or integer argument because mpf_set_str is just
wacky and I haven't gotten it working properly y
On 9/28/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> Should this PEP include changes to the struct module, or should it be a
> separate PEP?
Neither.
> I would like struct.pack() to return bytes and struct.unpack() to accept
> bytes or buffers but not strings.
This is already the case in 3.0a1.
Should this PEP include changes to the struct module, or should it be a
separate PEP?
I would like struct.pack() to return bytes and struct.unpack() to accept
bytes or buffers but not strings. The 's' and 'p' format specifier
should refer to bytes and not strings.
In protocol encoding and dec
On Sep 27, 2007, at 10:29 PM, Victor Stinner wrote:
> Hi,
>
> I read some days ago a discussion about GMP (license). I wanted to
> know if GMP
> is really better than current Python int/long implementation. So I
> wrote a
> patch for python 3000 subversion (rev. 58277).
>
> I changed long typ
19 matches
Mail list logo
