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 s
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 exce
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 I
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 rand
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 assemble
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
(#1536
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
Py
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 sys
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
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 fea
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?
>>
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
>>
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 t
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 so
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.
Note that http://www.openssl.org/support/faq.html#LEGAL1 says that we
can avoid building the problem sections wi
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 equa
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 be
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 advance
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
[email protected]
http://mail.python.org/mailm
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 wou
[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 intern
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 chan
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: Objects/typ
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
> > >
[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 misus
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 i
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 binar
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 t
Greg Ewing schrieb:
> If distributing the source doesn't violate the patent,
> and distributing a binary doesn't violate the patent,
> then what *would* constitute a violation of a software
> patent?
IANAL, but AFAICT, the rights controlled by patent law
are the right to make, to use, to sell, to
34 matches
Mail list logo
