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
Martin v. Löwis wrote:
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
M.-A. Lemburg schrieb:
Hiding programmer errors is not making life easier in the
long run, so I'm -1 on having the equality comparison return
False.
There is no error to hide here. The objects are inequal, period.
Instead we should generate a warning in Python 2.5 and introduce
the
I have supplied a patch that does everything needed to both make the
windows build process build OpenSSL with x86 assembly optimizations on
Win32 and to build the _hashlib.pyd module. It works for me.
The only thing the patch doesn't do is add _hashlib.pyd to the .msi
windows installer because
Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
Hiding programmer errors is not making life easier in the
long run, so I'm -1 on having the equality comparison return
False.
There is no error to hide here. The objects are inequal, period.
And in the case of dicts it hides errors randomly...
On Tue, Aug 08, 2006 at 08:26:08AM +0200, Martin v. L?wis wrote:
Gregory P. Smith schrieb:
Widely deployed popular applications use python for both large scale
hashing and ssl communications.
Yet, nobody has worried about performance in all these years to notice
that the assembler code
Hi all,
I've got another error porting our apps. It's a django app
and stops with (when pressing CTRL-C):
*** glibc detected *** free(): invalid pointer: 0xb684c650 ***
with MALLOC_CHECK=1 and gdb I get the following backtrace:
Program received signal SIGINT, Interrupt.
[Switching to Thread
Hi all,
The 2.5 change of id() to return positive ints-or-longs is likely to
cause quite some breakage in user programs that erroneously implemented
custom __hash__() functions returning a value based on an id(). This
was discussed a few times already but it showed up again as a bug report
Ralf Schmitt wrote:
Sorry for not using the bugtracker (sf sucks). Did you guys already
settle on a new one?
And sorry for bothering this list. It seems like this problem is related
to the python cdb module.
- Ralf
___
Python-Dev mailing
hello python-dev,
the following code hangs on FreeBSD 6.1-STABLE,
Python 2.5b3 (r25b3:51041, Aug 5 2006, 20:46:57)
$ cat pythontest
#!/usr/local/bin/python2.5
import os, thread, time, sys
def reboot():
print 'reboot'
os.execl(sys.argv[0], sys.argv[0])
thread.start_new_thread(reboot,
On 8/8/06, Bart Thate [EMAIL PROTECTED] wrote:
hello python-dev,
the following code hangs on FreeBSD 6.1-STABLE,
Python 2.5b3 (r25b3:51041, Aug 5 2006, 20:46:57)
Python 2.5 now uses system scope threads in FreeBSD just like
in other platforms. So python may behave different for corner
On Tue, 8 Aug 2006, Hye-Shik Chang wrote:
In my machine (FreeBSD 6.1), 2.4 and 2.5 work same.
What was the problem on your running? Did you install
it from the port?
i installed it from the python-devel port
Bart
___
Python-Dev mailing list
On Tue, 8 Aug 2006, Hye-Shik Chang wrote:
sorry i should reply a little better ;]
On 8/8/06, Bart Thate [EMAIL PROTECTED] wrote:
hello python-dev,
the following code hangs on FreeBSD 6.1-STABLE,
Python 2.5b3 (r25b3:51041, Aug 5 2006, 20:46:57)
Python 2.5 now uses system scope
Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
Failure to decode a string doesn't imply inequality.
If the failure is these bytes don't have a meaningful character
interpretation, then the bytes are *clearly* not equal to
some character string.
It implies
that the programmer needs to step
On Fri, 28 Jul 2006 18:00:36 -0400, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
The issue is that a proper fix that caches existence requires adding new
types to import.c and thus might appear to be more of a feature. I was
Armin Rigo wrote:
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
At 11:11 AM 8/8/2006 -0400, Jean-Paul Calderone wrote:
On Fri, 28 Jul 2006 18:00:36 -0400, Phillip J. Eby
[EMAIL PROTECTED] wrote:
At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
The issue is that a proper fix that caches existence requires adding new
types to
On Tue, 08 Aug 2006 12:04:16 -0400, Phillip J. Eby [EMAIL PROTECTED] wrote:
PEP 302 doesn't need to be changed, since Python now conforms to it again.
That is, every object in sys.path_importer_cache is either an importer or
None. It's just that there is an additional type of importer there
Martin v. Löwis wrote:
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 considering Unicode
M.-A. Lemburg schrieb:
If the programmer writes:
x = 'äöü'
y = u'äöü'
...
if x == y:
do_something()
then he clearly has had the intention to compare two character
strings.
Programmers make all kinds of mistakes when comparing objects,
assuming that things ought to be equal that
Armin Rigo schrieb:
Maybe the user should just be able to return any integer value from a
custom __hash__() without having to worry about not exceeding
sys.maxint.
After all the returned value has no real meaning. If a long is returned
we could take its hash again, and use that number
Jim Jewett schrieb:
The OpenSSL library implements some algorithms that are patented. The
source code should be fine to (re)distribute, but but there may be a
slight legal risk with distributing a binary.
I don't want to change the build process in that way (i.e. dropping a
feature) just
Martin Programmers make all kinds of mistakes when comparing objects,
Martin assuming that things ought to be equal that actually aren't:
py 1.6/math.pi*math.pi == 1.6
False
By extension, perhaps Computer Science departments should begin offering
Unicode Analysis as an advanced
Thomas Heller schrieb:
Approval requested for patch:
http://python.org/sf/1532975
What does the silence mean? Should I go ahead and commit this patch?
Thanks,
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
Thomas Heller schrieb:
Thomas Heller schrieb:
Approval requested for patch:
http://python.org/sf/1532975
What does the silence mean? Should I go ahead and commit this patch?
If it's not there already, you should add it to the PEP. If you think
it is release-critical (i.e. it would be
[Armin]
Maybe the user should just be able to return any integer value from a
custom __hash__() without having to worry about not exceeding
sys.maxint.
After all the returned value has no real meaning. If a long is returned
we could take its hash again, and use that number internally.
On 8/8/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jim Jewett schrieb:
The OpenSSL library implements some algorithms that are patented. The
source code should be fine to (re)distribute, but but there may be a
slight legal risk with distributing a binary.
I don't want to change the
Tim Peters schrieb:
It sounds fine to me, except I'm not immediately clear on which code
needs to be changed.
My change would essentially be the code below, in instance_hash and
slot_tp_hash; I have yet to add test cases and check for documentation
changes.
Regards,
Martin
Index:
On Tue, Aug 08, 2006 at 04:54:44PM -0400, Jim Jewett wrote:
On 8/8/06, Martin v. L?wis [EMAIL PROTECTED] wrote:
Jim Jewett schrieb:
The OpenSSL library implements some algorithms that are patented. The
source code should be fine to (re)distribute, but but there may be a
slight legal
[Georg Brandl, on
http://python.org/sf/1523610 - PyArg_ParseTupleAndKeywords
potential core dump
]
This one's almost fixed if we can decide what to do with levels.
I wrote some time ago:
With respect to this bug (which is about stack issues in Python/getargs.c
involving misuse of the
M.-A. Lemburg wrote:
Hiding programmer errors is not making life easier in the
long run, so I'm -1 on having the equality comparison return
False.
I don't see how this is greatly different from, e.g.
[1, 2] == (1, 2)
returning False. Comparing things of different types
may or may not
Martin v. Löwis wrote:
I personally don't think there is a risk
distributing the code (if there was, distribution of OpenSSL would also
be a risk); anybody /using/ a patented algorithm would violate the
patent.
If distributing the source doesn't violate the patent,
and distributing a binary
Patch / Bug Summary
___
Patches : 402 open ( +6) / 3360 closed ( +6) / 3762 total (+12)
Bugs: 861 open ( -3) / 6114 closed (+27) / 6975 total (+24)
RFE : 228 open ( +2) / 234 closed ( +0) / 462 total ( +2)
New / Reopened Patches
__
Replace
33 matches
Mail list logo
