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
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,
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
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
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:
> 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
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
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
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
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
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
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
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
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
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
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
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
[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
"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
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
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
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
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
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
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
25 matches
Mail list logo
