Hi,
Appologies for the lack of an sf#. I tried to submit this there but
couldn't. (sf is logging me out each time I visit a new page and it is
refusing my attempt to post anonymously).
Python 2.5b3 (trunk:51136M, Aug 7 2006, 10:48:15)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
The need for
M.-A. Lemburg schrieb:
>> There's no disputing that an exception should be raised
>> if the string *must* be interpretable as characters in
>> order to continue. But that's not true here if you allow
>> for the interpretation that they're simply objects of
>> different (duck) type and therefore une
M.-A. Lemburg schrieb:
> Python just doesn't know the encoding of the 8-bit string, so can't
> make any assumptions on it. As result, it raises an exception to inform
> the programmer.
Oh, Python does make an assumption what the encoding is: it assumes
it is the system encoding (i.e. "ascii"). The
Michael Kent schrieb:
> Because of a requirement to remain compatible with AIX 4.3, I have been forced
> to stay with Python 2.3, because while 2.4 would compile under AIX 4.3, it
> would
> segfault immediately when run.
>
> I'm happy to report that Python 2.5b3 compiles and runs fine under AIX 4
Gregory P. Smith schrieb:
> Whoever knows how the windows build process works and controls the
> python 2.5 windows release builds could you please make sure the
> hashlib module gets built + linked with OpenSSL rather than falling
> back to its much slower builtin implementations.
If the project
Martin v. Löwis wrote:
> [snip..]
> Expanding this view to Unicode should mean that a unicode
> string U equals a byte string B if
> U.encode(system_encode) == B or B.decode(system_encoding) == U,
> and that they don't equal otherwise (e.g. if the conversion
> fails with a "not convertible" excepti
"Neal Norwitz" <[EMAIL PROTECTED]> wrote:
> Things are getting better, but we still have some really important
> outstanding issues. PLEASE CONTINUE TESTING AS MUCH AS POSSIBLE.
I've run into a problem with a big application that I wasn't able to
reproduce with a small example. I've submitted a
[EMAIL PROTECTED] schrieb:
> The code (exception handler added to demonstrate and work around
> the problem):
>
> try :
> h = hash(p)
> except OverflowError, e:
> print type(p), p, id(p), e
> h = id
Michael Foord wrote:
> Martin v. Löwis wrote:
>
>>[snip..]
>>Expanding this view to Unicode should mean that a unicode
>>string U equals a byte string B if
>>U.encode(system_encode) == B or B.decode(system_encoding) == U,
>>and that they don't equal otherwise (e.g. if the conversion
>>fails with a
Martin v. Löwis wrote:
> [EMAIL PROTECTED] schrieb:
>> >>> class X(object):
>> ... def __hash__(self): return id(self)
>> ...
>> >>> hash (X())
>> Traceback (most recent call last):
>> File "", line 1, in
>> OverflowError: long int too la
David Hopwood schrieb:
> I disagree. Unicode strings should always be considered distinct from
> non-ASCII byte strings. Implicitly encoding or decoding in order to
> perform a comparison is a bad idea; it is expensive and will often do
> the wrong thing.
That's a pretty irrelevant position at thi
Hi,
On Thu, Aug 03, 2006 at 07:53:11PM +0200, M.-A. Lemburg wrote:
> > I though I'd heard (from Guido here or on the py3k list) that it was only
> > 1 < u'abc' that would raise an exception, and that 1 == u'abc' would still
> > evaluate to False. Did I misunderstand?
>
> Could be that I'm wron
On Mon, Aug 07, 2006 at 03:16:22PM +0200, "Martin v. L?wis" wrote:
> Gregory P. Smith schrieb:
> > Whoever knows how the windows build process works and controls the
> > python 2.5 windows release builds could you please make sure the
> > hashlib module gets built + linked with OpenSSL rather than
David Hopwood wrote:[snip..]
>
>
>>> we should, of course, continue to use the one we always used (for
>>> "ascii", there is no difference between the two).
>>>
>> +1
>>
>> This seems the most (only ?) logical solution.
>>
>
> No; always considering Unicode and non-ASCII byte strings
I'm nervous about this change being made at this stage of the release process.
It seems to me to have a chance of causing breakages - admittedly a small
chance, but one that's higher than I'd like.
I'd also like to make sure that the PCBuild8 directory is updated at the same
time - with the rec
On Tue, Aug 08, 2006 at 03:25:46AM +1000, Anthony Baxter wrote:
> I'm nervous about this change being made at this stage of the release
> process.
> It seems to me to have a chance of causing breakages - admittedly a small
> chance, but one that's higher than I'd like.
Sigh. Half the reason I
Michael Foord wrote:
> David Hopwood wrote:[snip..]
>
we should, of course, continue to use the one we always used (for
"ascii", there is no difference between the two).
>>>
>>> +1
>>>
>>> This seems the most (only ?) logical solution.
>>
>> No; always considering Unicode and non-ASCII b
Michael Foord wrote:
> David Hopwood wrote:[snip..]
>>
we should, of course, continue to use the one we always used (for
"ascii", there is no difference between the two).
>>> +1
>>>
>>> This seems the most (only ?) logical solution.
>>>
>> No; always considering Unicod
David Hopwood schrieb:
> Michael Foord wrote:
>> David Hopwood wrote:[snip..]
>>
> we should, of course, continue to use the one we always used (for
> "ascii", there is no difference between the two).
+1
This seems the most (only ?) logical solution.
>>> No; always considerin
Gregory P. Smith schrieb:
> hashlib's OpenSSL implementation on windows comes in the form of a
> 300k _hashlib.pyd library.
What do you mean by "comes"? I can't find any _hashlib.vcproj file
inside the PCbuild directory.
>> I believe that the performance of the OpenSSL routines depends on
>> the
On Tue, Aug 08, 2006 at 01:46:13AM +0200, "Martin v. L?wis" wrote:
> Gregory P. Smith schrieb:
> > hashlib's OpenSSL implementation on windows comes in the form of a
> > 300k _hashlib.pyd library.
>
> What do you mean by "comes"? I can't find any _hashlib.vcproj file
> inside the PCbuild directory
Gregory P. Smith schrieb:
> Sigh. Half the reason I did the hashlib work was to get much faster
> optimized versions of the hash algorithms into python. I'll be
> disappointed if that doesn't happen.
Sad as it sounds, it appears you just did half of the work, then
(omitting the Windows build pro
Armin Rigo schrieb:
> I also seem to remember that TypeErrors should only signal ordering
> non-sense, not equality. In this case, I'm on the opinion that unicode
> objects and completely-unrelated strings of random bytes should
> successfully compare as unequal, but I'm not enough of a unicode us
On Tue, Aug 08, 2006 at 02:23:02AM +0200, "Martin v. L?wis" wrote:
> Gregory P. Smith schrieb:
> > Sigh. Half the reason I did the hashlib work was to get much faster
> > optimized versions of the hash algorithms into python. I'll be
> > disappointed if that doesn't happen.
>
> Sad as it sounds,
Gregory P. Smith schrieb:
> So is it worth my time doing this in a hurry for 2.5 or do other
> people really just not care if python for windows uses a slow OpenSSL?
As I said: I would accept patches. If you arrange for a separate
_hashlib.pyd file, most of my concerns would go away. So please
do
25 matches
Mail list logo
