On 9/8/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote:
> On 9/8/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Would anyone be opposed to rehosting PyLong on top of GMP?
> >
> > I would be opposed. It's LGPL'ed, so you would have to ship GMP sources
> > with any Python binary that you distri
If the Python community is just noticing the Hsieh hash, that implies
that the Bob Jenkins hashes are probably unknown as well. Behold:
http://burtleburtle.net/bob/hash/doobs.html
To save you a little head-scratching, the functions you want to play
with are hashlittle()/hashlittle2() in "l
[Guido]
> I'd like Tim Peters's input on this before we change it. I seem to
> recall that there's an aspect of non-randomness to the existing hash
> function that's important when you hash many closely related strings,
> e.g. "0001", "0002", "0003", etc., into a dictionary. Though it's been
> so l
On 9/8/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Would anyone be opposed to rehosting PyLong on top of GMP?
>
> I would be opposed. It's LGPL'ed, so you would have to ship GMP sources
> with any Python binary that you distribute.
The LGPL has no requirement that you convey source for un
A new version is attached; cleaned up and simplified based on your original
comments.
On 8/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> That's a huge patch to land so close before a release. I'm not sure I
> like the immutability API -- it won't be useful unless we add a hash
> method, a
> Would anyone be opposed to rehosting PyLong on top of GMP?
I would be opposed. It's LGPL'ed, so you would have to ship GMP sources
with any Python binary that you distribute.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
http://
On 9/8/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Speaking of PyLong, and its' minor awkwardness to work with in C (you
> > either have to convert to another multiple-precision type through a
> > string, or use Python's arithmetic operators directly), was there any
> > thought given to us
> >> Why do you say that doing the work is not a problem? I see it as
> >> a major problem.
> >
> > I'm willing to either do the work myself, or have someone else from the
> > secops team at OLPC do it.
>
> It's not something that a single person can well do. You will also need
> to design APIs,
> Speaking of PyLong, and its' minor awkwardness to work with in C (you
> either have to convert to another multiple-precision type through a
> string, or use Python's arithmetic operators directly), was there any
> thought given to using something like GPM's mpz_t as the backing data
> type?
I ne
On 9/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/8/07, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> > I see that PyInt_* functions are aliases for PyLong_*. Which ones
> > should I use for the long term? There are no PyInt equivalents of
> > PyLong_FromLongLong nor PyLong_AsL
> Hm, then perhaps rangeobject.c shouldn't use it?
That use is correct also; the int_range_iter is also an
optimization. It does not matter that the result is not correct;
if one bound is >2**30, it will create a longrangeiter, even though
an int one would still be sufficient.
Regards,
Martin
___
Hm, then perhaps rangeobject.c shouldn't use it?
On 9/8/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Why is _PyLong_FitsInLong private?
> >
> > I don't know; perhaps because it doesn't always give the best answer.
>
> Its sole purpose is to support PyInt_CheckExact. There is some code
> t
>> Why is _PyLong_FitsInLong private?
>
> I don't know; perhaps because it doesn't always give the best answer.
Its sole purpose is to support PyInt_CheckExact. There is some code
that relies that after PyInt_CheckExact succeeds, it is safe to do
PyInt_AsLong. When I defined PyInt_CheckExact to P
On 9/8/07, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> I see that PyInt_* functions are aliases for PyLong_*. Which ones
> should I use for the long term? There are no PyInt equivalents of
> PyLong_FromLongLong nor PyLong_AsLongLong.
Use PyLong for now. Eventually we may rename them all
I see that PyInt_* functions are aliases for PyLong_*. Which ones
should I use for the long term? There are no PyInt equivalents of
PyLong_FromLongLong nor PyLong_AsLongLong.
Should I continue to use PyUnicode_* functions for the new str?
What is the status of the str8 type? Is it kept temporaril
Marcin 'Qrczak' Kowalczyk schrieb:
> and fails on print.
Already fixed. :)
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor ei
and fails on print.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
h
On 9/8/07, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Dnia 14-08-2007, Wt o godzinie 21:56 -0700, Guido van Rossum napisał(a):
>
> > (2) newline='': input with untranslated universal newlines mode; lines
> > may end in \r, \n, or \r\n, and these are returned untranslated.
> >
> > (3) ne
Dnia 14-08-2007, Wt o godzinie 21:56 -0700, Guido van Rossum napisał(a):
> (2) newline='': input with untranslated universal newlines mode; lines
> may end in \r, \n, or \r\n, and these are returned untranslated.
>
> (3) newline='\r', newline='\n', newline='\r\n': input lines must end
> with the
19 matches
Mail list logo
