Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Stephen J. Turnbull
Ralf W. Grosse-Kunstleve writes: > Stephen J. Turnbull wrote: [really butchered quotes omitted] > [Prof. George Sheldrick] is one of the brightest people you'll find > on this planet. Ad hominem argument. My point is simply that he knows what he needs and said so. He doesn't need a languag

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Ralf W. Grosse-Kunstleve
Stephen J. Turnbull wrote: > Some, like the "field heavyweight" quoted by the OP, are refreshingly > pragmatic about it. They're quite happy to use a language that is > pretty crappy for most purposes today considered practical because it > does a great job of c

Re: [Python-3000] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Stephen J. Turnbull
Mike Meyer writes: > On Tue, 05 Feb 2008 08:20:00 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]> > wrote: > > Mike Meyer writes: > > > On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <[EMAIL > > PROTECTED]> wrote: > > > Wrong. The recommend "make install" overwrites the "python"

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Stephen J. Turnbull
Adam Olsen writes: > > Setuptools [pybang] works with versions 2.3 through 2.5, but of > > course that's because of the .exe wrappers. As independent corroboration, this is basically the same way that DJGPP (the DOS-extended version of GCC) provides Unix-y features like access to the environmen

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Christian Heimes
Brett Cannon wrote: > Well, I am a little leery of another free list. I personally don't > love the fact that there are various caches and free lists laying > about in the code without a central place to turn them off or clear > them (or at least list them in a comment somewhere). And the problem >

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Brett Cannon
On Feb 5, 2008 2:30 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I think Christian means single digit integers. But I thought we > > already did this for positive numbers? So is the proposal to also > > cover negative numbers? > > We don't have a free list, but a cache for them, and only fo

Re: [Python-3000] pickle, cPickle, and the standard library (was Re: [Python-Dev] inst_persistent_id)

2008-02-05 Thread Charles Merriam
I agree. A wiki page for "leaving just the head of the snake" would be the correct solution. On Feb 4, 2008 4:34 PM, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 2/4/08, Charles Merriam <[EMAIL PROTECTED]> wrote: > > What about a formal dependency plan instead? > > > Python would remain 'batteries

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Martin v. Löwis
> I think Christian means single digit integers. But I thought we > already did this for positive numbers? So is the proposal to also > cover negative numbers? We don't have a free list, but a cache for them, and only for numbers between -5 and +256. Christian proposes a freelist, similar to the s

Re: [Python-3000] pickle, cPickle, and the standard library (was Re: [Python-Dev] inst_persistent_id)

2008-02-05 Thread Jesus Cea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: | On Jan 25, 2008, at 12:07 AM, Guido van Rossum wrote: |> (*) I can only speculate that it's because Jim, whose ZODB is probably |> pickle's most intensive user, | | Maybe, but I'm not sure. Any persistence system is pickle intensiv

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Christian Heimes
Martin v. Löwis wrote: > I'm puzzled as to how you arrive at this upper bound. You can surely > have more than 2**16 integer objects whose abs values are all > below 2**15, no? Oh ... I see. You are right and I did a mistake by confusing the amount of objects with the range. I'd better add an uppe

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Martin v. Löwis
> Since the free list is limited to small longs, it will consume less than > 1,5 MB on a 64bit OS and less than 900kb on a 32bit OS in a worst case > scenario (2 * (1<<15) ~ 65k objects with a size of 14 / 22 byte each). I'm puzzled as to how you arrive at this upper bound. You can surely have mor

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Christian Heimes
Brett Cannon wrote: > I think Christian means single digit integers. But I thought we > already did this for positive numbers? So is the proposal to also > cover negative numbers? Ne, we don't use a free list for longs. In the 2.x series floats and ints are allocated in blocks of 1000 objects. The

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Christian Heimes
[EMAIL PROTECTED] wrote: > I'm not sure what you mean by "size of 1 or -1". Do you mean you only keep > the numbers 1 and -1 on the free list? It's not obvious to me what a size > of -1 is. Do you mean positive and negative numbers which fit in one byte > or one long word? I should have explain

Re: [Python-3000] Free list for small longs

2008-02-05 Thread Brett Cannon
On Feb 5, 2008 12:13 PM, <[EMAIL PROTECTED]> wrote: > > Christian> I've implemented a free list for small long objects with a > Christian> size of 1 or -1. > > I'm not sure what you mean by "size of 1 or -1". Do you mean you only keep > the numbers 1 and -1 on the free list? It's not obv

Re: [Python-3000] Free list for small longs

2008-02-05 Thread skip
Christian> I've implemented a free list for small long objects with a Christian> size of 1 or -1. I'm not sure what you mean by "size of 1 or -1". Do you mean you only keep the numbers 1 and -1 on the free list? It's not obvious to me what a size of -1 is. Do you mean positive and nega

[Python-3000] Free list for small longs

2008-02-05 Thread Christian Heimes
I've implemented a free list for small long objects with a size of 1 or -1. I wanted to test how large the malloc overhead is. The result was astonishing. The free list quadrupled the speed of a simple test: $ ./python -m timeit "for i in range(100): list(range(1000))" Without patch: 10 loops, be

Re: [Python-3000] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Robert Brewer
I took the liberty of asking DRH's advice based on his experiences with sqlite/2/3, and he graciously replied: > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 05, 2008 10:02 AM > To: Robert Brewer > Subject: Re: Python 3 needs your help >

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Adam Olsen
On Feb 5, 2008 10:57 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:43 AM 2/5/2008 -0700, Adam Olsen wrote: > >So why don't we add a windows equivalent of the shebang? Files could > >then start like this: > > > >#!/usr/bin/python2.3 > >#¡C:/python23/python > > FYI, setuptools uses and suppo

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Phillip J. Eby
At 10:43 AM 2/5/2008 -0700, Adam Olsen wrote: >So why don't we add a windows equivalent of the shebang? Files could >then start like this: > >#!/usr/bin/python2.3 >#¡C:/python23/python FYI, setuptools uses and supports #! lines on Windows, with the executable path in quotes if it contains spaces

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Adam Olsen
On Feb 4, 2008 4:56 PM, Mike Meyer <[EMAIL PROTECTED]> wrote: > On Mon, 4 Feb 2008 15:34:56 -0800 (PST) "Ralf W. Grosse-Kunstleve" <[EMAIL > PROTECTED]> wrote: > > As Python developers you have to realize that for many people Python is > > "just" a core around which they build much bigger applicat

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Mike Meyer
On Wed, 06 Feb 2008 01:01:05 +1000 Nick Coghlan <[EMAIL PROTECTED]> wrote: > Ralf W. Grosse-Kunstleve wrote: > > Nick Coghlan wrote: > > > >> I personally haven't seen anything to convince me that the 2.x -> 3.0 > >> upgrade cycle is going to be significantly worse from a deployment point > >>

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Mike Meyer
On Mon, 4 Feb 2008 15:34:56 -0800 (PST) "Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote: > As Python developers you have to realize that for many people Python is > "just" a core around which they build much bigger applications. If the > success of Python is to continue, you have to give your

Re: [Python-3000] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Mike Meyer
On Tue, 05 Feb 2008 08:20:00 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote: > Mike Meyer writes: > > On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <[EMAIL > PROTECTED]> wrote: > > > Marcin ___Qrczak___ Kowalczyk writes: > > > > Dnia 03-02-2008, N o godzinie 10:24 +0900, Ste

Re: [Python-3000] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Mike Meyer
On Mon, 04 Feb 2008 20:22:04 +0900 "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote: > Marcin ___Qrczak___ Kowalczyk writes: > > Dnia 03-02-2008, N o godzinie 10:24 +0900, Stephen J. Turnbull pisze: > > > I don't see any need to shorten "python3.0" to "python3". > > There is a need. Using #!/usr

[Python-3000] PYTHONPATH in Python 3.0 (was: Namespaces are one honking ...)

2008-02-05 Thread skip
James> Not much fun for users of the PYTHONPATH env var though, eh? PYTHONPATH3 anyone? Or maybe .pth files are sufficient. So far I've been able to mangle my PYTHONSTARTUP file to work with both Python 2 and Python 3. That's not very sophisticated code though. Skip __

Re: [Python-3000] [Python-ideas] Namespaces are one honking great idea -- let's do more of those!

2008-02-05 Thread Nick Coghlan
Ralf W. Grosse-Kunstleve wrote: > Nick Coghlan wrote: > >> I personally haven't seen anything to convince me that the 2.x -> 3.0 >> upgrade cycle is going to be significantly worse from a deployment point >> of view than a 2.x -> 2.(x+2) upgrade cycle where breakages are also >> possible (e.g.