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
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
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
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
[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
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
> > >
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 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
[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
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
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
http://mail.python.org/mailm
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
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
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
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
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
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
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
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
>>
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?
>>
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
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 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
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 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
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, (
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
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
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 -
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
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
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
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
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
34 matches
Mail list logo
