Re: [Python-3000] C API for ints and strings

On 9/12/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > On 9/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Can I just shortcut this discussion saying that we will *not* switch > > to use GMP? It's just not going to happen. Period. End of discussion. > > I figured that was assumed once it

Re: [Python-3000] C API for ints and strings

On 9/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Can I just shortcut this discussion saying that we will *not* switch > to use GMP? It's just not going to happen. Period. End of discussion. I figured that was assumed once it was pointed out that it didn't work on Intel macs... I'm pretty

Re: [Python-3000] C API for ints and strings

Can I just shortcut this discussion saying that we will *not* switch to use GMP? It's just not going to happen. Period. End of discussion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.o

Re: [Python-3000] C API for ints and strings

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 12, 2007, at 1:43 PM, Neil Schemenauer wrote: > Larry Hastings <[EMAIL PROTECTED]> wrote: >> I am opposed to using LGPL- or GPL-licensed code in Python. > > Me too. Also, I don't see the point. Python's current long integer > performance is g

Re: [Python-3000] C API for ints and strings

Larry Hastings <[EMAIL PROTECTED]> wrote: > I am opposed to using LGPL- or GPL-licensed code in Python. Me too. Also, I don't see the point. Python's current long integer performance is good enough for the large majority of Python users. For the few specialized users, an extension module should

Re: [Python-3000] C API for ints and strings

On 9/12/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > [cpu rant] > Off topic: not true. The Pentium D is the final Pentium 4 netburst > architecture based design. It is not at all close to the Pentium M. The M > is much more a derivative of the pentium pro,ii,iii, & iii-m before it as > cor

Re: [Python-3000] C API for ints and strings

> The Pentium M and Pentium D are much more alike, architecturally, than > either and the Pentium 4, [cpu rant] Off topic: not true. The Pentium D is the final Pentium 4 netburst architecture based design. It is not at all close to the Pentium M. The M is much more a derivative of the pentium

Re: [Python-3000] C API for ints and strings

Nick Coghlan wrote: > The LGPL and GPL have different aims from the PSF license, with a much > greater focus on preserving freedom for the end-user, Seems to me they go somewhat beyond "preserving freedoms" and into other areas. It's one thing to *allow* people to use the source if they can get i

Re: [Python-3000] C API for ints and strings

On 9/11/07, Paul Moore <[EMAIL PROTECTED]> wrote: > On 11/09/2007, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > > 3.0: 10 loops, best of 3: 6.76 sec per loop > > > > 2.6: 10 loops, best of 3: 2.61 sec per loop > > > > > > I can't quit

Re: [Python-3000] C API for ints and strings

Martin v. Löwis wrote: > I personally never said what I think of the LGPL. I was merely trying > to explain what it actually says. FWIW, I quite like both the GPL, and > the LGPL, and applaud the motivations behind it. That's why I prefer > to follow it faithfully, and in its spirit, rather than tr

Re: [Python-3000] C API for ints and strings

On 11/09/2007, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > 3.0: 10 loops, best of 3: 6.76 sec per loop > > > 2.6: 10 loops, best of 3: 2.61 sec per loop > > > > I can't quite reproduce these results. On a 3.2GHz Pentium 4, > > running

Re: [Python-3000] C API for ints and strings

> In the GPL FAQ (). Specifically: > > Can I put the binaries on my Internet server and put the source on a > different Internet site? Ok. As you say, this applies to downloading only. > Of course, as several people have now pointed out, non-internet >

Re: [Python-3000] C API for ints and strings

On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > 3.0: 10 loops, best of 3: 6.76 sec per loop > > 2.6: 10 loops, best of 3: 2.61 sec per loop > > I can't quite reproduce these results. On a 3.2GHz Pentium 4, > running Linux 2.6.21, gcc 4.1.3, I get > > 3.0: 10 loops, best of 3: 728 msec

Re: [Python-3000] C API for ints and strings

On 9/11/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > I guess anything is debatable, but the LGPL explicitly defines programs > statically-linked with LGPL code as being "derivative works": Where exactly does it do that? The GPL does that, but not the LGPL. In fact, the LGPL does not define no

Re: [Python-3000] C API for ints and strings

On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > If python.org agreed to host the GMP source, that would suffice for > > all people distributing python binaries (they could then just refer to > > the GMP source download as a link). > > It would not if they don't distribute the binary th

Re: [Python-3000] C API for ints and strings

> 3.0: 10 loops, best of 3: 6.76 sec per loop > 2.6: 10 loops, best of 3: 2.61 sec per loop I can't quite reproduce these results. On a 3.2GHz Pentium 4, running Linux 2.6.21, gcc 4.1.3, I get 3.0: 10 loops, best of 3: 728 msec per loop 2.6: 10 loops, best of 3: 558 msec per loop So it's only 30

Re: [Python-3000] C API for ints and strings

Nicholas Bastin wrote: As for the user-replaceable shared library part, that's up for considerable debate. It's unlikely that static linkage legally creates a derivative work (that would be pretty unreasonable in computer science terms), but it's never been tested in court, so static linking wou

Re: [Python-3000] C API for ints and strings

> Interesting, I didn't look at the code (obviously), but my > understanding was that it was only positive integers below 100. See NSMALLPOSINTS and NSMALLNEGINTS. It's 257 positive ints since r42552, contributed through bugs.python.org/1436243. Regards, Martin ___

Re: [Python-3000] C API for ints and strings

> If python.org agreed to host the GMP source, that would suffice for > all people distributing python binaries (they could then just refer to > the GMP source download as a link). It would not if they don't distribute the binary through download. If they put it on some media, or preinstalled on a

Re: [Python-3000] C API for ints and strings

>> The first right of the user is to get the source code >> easily, without having to beg for it. Only then it is also >> the user's right to modify it, and use the modified version >> in the application. > > Where does begging come into it? As long as the user > is provided with information which

Re: [Python-3000] C API for ints and strings

On 9/10/07, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Nicholas Bastin" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > | Yeah, my point was mostly an aside to anyone that might have > | questioned my earlier results of a 2.3x slowdown on integer-sized > | values because I used 1

Re: [Python-3000] C API for ints and strings

"Nicholas Bastin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Yeah, my point was mostly an aside to anyone that might have | questioned my earlier results of a 2.3x slowdown on integer-sized | values because I used 1. A quick switch to 200 netted the exact same | results, Curr

Re: [Python-3000] C API for ints and strings

On 9/10/07, Larry Hastings <[EMAIL PROTECTED]> wrote: > > Greg Ewing wrote: > If there's a link on the same web page that works > when the user clicks on it, I don't think they're > even going to notice the difference. > > They'll notice the difference when they want to redistribute Python, when

Re: [Python-3000] C API for ints and strings

On 9/10/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > > The first right of the user is to get the source code > > easily, without having to beg for it. Only then it is also > > the user's right to modify it, and use the modified version > > in the application. > > Where doe

Re: [Python-3000] C API for ints and strings

Marcin 'Qrczak' Kowalczyk wrote: > The major technical problem with GMP is that an out of memory condition > during computation is a fatal error, GMP does not provide a way to > recover from it. If using GMP itself is not feasible, then perhaps some algorithms could be extracted from it in areas w

Re: [Python-3000] C API for ints and strings

Greg Ewing wrote: If there's a link on the same web page that works when the user clicks on it, I don't think they're even going to notice the difference. They'll notice the difference when they want to redistribute Python, when they note the new licensing-based restrictions ("GMP must be in a

Re: [Python-3000] C API for ints and strings

Martin v. Löwis wrote: > The first right of the user is to get the source code > easily, without having to beg for it. Only then it is also > the user's right to modify it, and use the modified version > in the application. Where does begging come into it? As long as the user is provided with inf

Re: [Python-3000] C API for ints and strings

On 9/10/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/10/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > > > I did redo my benchmark using 200 as the increment number instead of > > > > 1, to duck any impact from the interning of small value ints in 2.6, > > > > and it made no discernib

Re: [Python-3000] C API for ints and strings

On 9/10/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > > I did redo my benchmark using 200 as the increment number instead of > > > 1, to duck any impact from the interning of small value ints in 2.6, > > > and it made no discernible difference in the results. > > > > I'm sorry, I've lost conte

Re: [Python-3000] C API for ints and strings

On 9/10/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > On 9/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > > > I'm not suggesting that Python handle small ints itself and

Re: [Python-3000] C API for ints and strings

On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > On 9/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > > I'm not suggesting that Python handle small ints itself and then farm > > > out large integer computations, I'm suggesting

Re: [Python-3000] C API for ints and strings

Dnia 09-09-2007, N o godzinie 21:27 -0400, Jim Jewett napisał(a): > If python handled small ints itself, and only farmed out the "large" > ones, If GMP is used, it's definitely worth to have a non-GMP representation for small integers, because GMP itself does not do it. A GMP integer is represent

Re: [Python-3000] C API for ints and strings

> I think it's just trying to say dynamic rather than static > linking, not that the library has to be a pre-existing > one. The important thing is that the library can be > updated just by replacing a file, without having to > re-link the executable. > > So Windows DLLs qualify, as far as I can s

Re: [Python-3000] C API for ints and strings

On 9/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > I'm not suggesting that Python handle small ints itself and then farm > > out large integer computations, I'm suggesting that since we've > > already coalesced small ints into 'large'

Re: [Python-3000] C API for ints and strings

On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > I'm not suggesting that Python handle small ints itself and then farm > out large integer computations, I'm suggesting that since we've > already coalesced small ints into 'large' ones, we might want to > review the performance implications o

Re: [Python-3000] C API for ints and strings

On 9/9/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 9/9/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > > > I think it's just trying to say dynamic rather than static ... > > library can be updated just by replacing a file, ... > > > So Windows DLLs qualify, as far as I can see. > > How many external

Re: [Python-3000] C API for ints and strings

On 9/9/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > I think it's just trying to say dynamic rather than static ... > library can be updated just by replacing a file, ... > So Windows DLLs qualify, as far as I can see. How many external library calls would need to be resolved at runtime for the fo

Re: [Python-3000] C API for ints and strings

Martin v. Löwis wrote: > b) Use a suitable shared library mechanism for linking with the Library. > A suitable mechanism is one that (1) uses at run time a copy of the > library already present on the user's computer system, rather than > copying library functions into the executable, and (2) will

Re: [Python-3000] C API for ints and strings

Jim Jewett wrote: > It has now come to the point where a > compiler should be assumed to miscompile GMP. > ... > It doesn't work on the Intel Macintoshes, and the workarounds are so > ugly that they won't be applied to the trunk. Sounds like it's been optimised for speed over portability in a real

Re: [Python-3000] C API for ints and strings

On 9/9/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > a) Accompany the work with the complete corresponding machine-readable > > source code for the Library > > But if it's like the regular GPL, you can just tell people > where to get the source -- you don't have to physical

Re: [Python-3000] C API for ints and strings

Martin v. Löwis wrote: > a) Accompany the work with the complete corresponding machine-readable > source code for the Library But if it's like the regular GPL, you can just tell people where to get the source -- you don't have to physically provide it yourself. -- Greg ___

Re: [Python-3000] C API for ints and strings

On 9/9/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 9/8/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > 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-preci

Re: [Python-3000] C API for ints and strings

On 9/8/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > 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 arithme

Re: [Python-3000] C API for ints and strings

On 9/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > "d) If distribution of the work is made by offering access to copy > > from a designated place, offer equivalent access to copy the above > > specified materials from the same place." > > This is the same as "distribute the source code".

Re: [Python-3000] C API for ints and strings

>> You could use _PyLong_AsByteArray. > > I'm scared by the underscore. If that helps, feel free to submit a patch to remove the underscore, and document the function properly. Regards, Martin ___ Python-3000 mailing list Python-3000@python.org http:/

Re: [Python-3000] C API for ints and strings

Dnia 09-09-2007, N o godzinie 15:24 +0200, "Martin v. Löwis" napisał(a): > You could use _PyLong_AsByteArray. I'm scared by the underscore. -- __("< Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ _

Re: [Python-3000] C API for ints and strings

> I actually need to convert it to mpz_t, which is best done via text > in a C string in a base which is a power of 2. Since PyUnicode_Format > for Python3 int creates a byte string first, it's quite silly to let > a byte string be converted to a Unicode string and then back. You could use _PyLong

Re: [Python-3000] C API for ints and strings

Since PyString_Format is deprecated, is there a better way to convert a Python3 int which doesn't fit in a C long to a hex representation in a C string, than PyUnicode_Format and iterating over characters, casting them from Unicode to bytes? I actually need to convert it to mpz_t, which is best do

Re: [Python-3000] C API for ints and strings

> You're being awfully selective in your reading. On purpose. All alternatives can be ruled out quickly as unfeasible, or equivalent to "distribute the source code". > 6a is but one of 5 choices. So which of these would you recommend? > "b) Use a suitable shared library mechanism for linking wi

Re: [Python-3000] C API for ints and strings

On 9/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > The LGPL has no requirement that you convey source for unmodified > > libraries. Linkage does not imply modification. > > Why do you say that? LGPL 2.1, section 6a) (talking about > "work that uses the Library"): > > a) Accompany the work

Re: [Python-3000] C API for ints and strings

> The LGPL has no requirement that you convey source for unmodified > libraries. Linkage does not imply modification. Why do you say that? LGPL 2.1, section 6a) (talking about "work that uses the Library"): a) Accompany the work with the complete corresponding machine-readable source code for th

Re: [Python-3000] C API for ints and strings

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

Re: [Python-3000] C API for ints and strings

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

Re: [Python-3000] C API for ints and strings

> 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://

Re: [Python-3000] C API for ints and strings

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

Re: [Python-3000] C API for ints and strings

> 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

Re: [Python-3000] C API for ints and strings

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

Re: [Python-3000] C API for ints and strings

> 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 ___

Re: [Python-3000] C API for ints and strings

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

Re: [Python-3000] C API for ints and strings

>> 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

Re: [Python-3000] C API for ints and strings

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

[Python-3000] C API for ints and strings

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