Re: [Python-Dev] deque alternative (was: Linked lists)

Hi all, not addressing anybody directly here, but this thread is about my dequeue question. It would just be nice if you could use the original thread topic or a different one to discuss the original question. -- Christian Tismer :^) tismerysoft GmbH

Re: [Python-Dev] Python + Visual C++ 8.0?

Ralf W. Grosse-Kunstleve wrote: > I am using a Visual Studio 2005 Professional installation. I also ran > vcredist_x86.exe. Moving msvc[mpr]80.dll to a directory on PATH didn't > help. However, standalone executables work OK without any gymnastics. > Does anyone know what the problem could be with

[Python-Dev] A few questions about setobject

Hello, I'm going over setobject.c/setobject.h, while trying to change them to support cheap frozen-copying. I have a few questions. 1) This is a part of setobject.h: typedef struct { long hash; PyObject *key; } setentry; typedef struct _setobject PySetObject; struct _setobject {

Re: [Python-Dev] that library reference, again

On 12/26/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > as seen on the doc-sig: > > > > > javadoc's > > > > > > > > [EMAIL PROTECTED] os.popen} > > > > > > > > is even shorter. > > > > > > > > hmm. maybe a combination of rest/html/whatever and pythondoc markup > > > > would be the ultimate too

Re: [Python-Dev] deque alternative (was: Linked lists)

At 11:04 AM 12/26/2005 -0800, Josiah Carlson wrote: >Not necessarily so as I have pointed out above. You said yourself; >practicality beats purity. While using cons cells are pure, as us using >only flat lists are pure, flat lists are practically smaller than cons >cells in certain cases (by a fa

Re: [Python-Dev] deque alternative (was: Linked lists)

... [Tim Peters] >> I'm sure he did ;-) Consider a very simple graph, a skinny tree >> rooted at `A` that branches once "at the end", represented by a dict >> of adjacency lists: [Josiah Carlson] > Are you sure? Of what? > ... > But one doesn't _need_ to use flat lists. Of course not. You d

[Python-Dev] that library reference, again

as seen on the doc-sig: > > > javadoc's > > > > > > [EMAIL PROTECTED] os.popen} > > > > > > is even shorter. > > > > > > hmm. maybe a combination of rest/html/whatever and pythondoc markup > > > would be the ultimate tool for the library reference... > > > > <* heavy clapping sound of my foot

Re: [Python-Dev] deque alternative (was: Linked lists)

> [restoring context and attributions lost in the original] > > [Tim Peters] > Like Phillip Eby, I use 2-tuples for this when I feel the need > (usually during a backtracking graph search, to keep track of paths > back to the root in a space-efficient way), and am happy with that.

[Python-Dev] Python + Visual C++ 8.0?

We have a bunch of C++ extensions (Boost.Python) that work fine under Windows when compiled with Visual C++ 7.1. With a few minor tweaks all extensions also compile with Visual C++ 8.0, but trying to "import" any of the extensions fails with this message (shown in a pop-up box): This application

Re: [Python-Dev] deque alternative (was: Linked lists)

[restoring context and attributions lost in the original] [Tim Peters] Like Phillip Eby, I use 2-tuples for this when I feel the need (usually during a backtracking graph search, to keep track of paths back to the root in a space-efficient way), and am happy with that. [Josiah Carl

Re: [Python-Dev] NotImplemented reaching top-level

2005/12/26, Armin Rigo <[EMAIL PROTECTED]>: > Done in patch #1390657. Fantastic, Armin, thank you! > nb_add and nb_multiply should be tried. I don't think that this would > break existing C or Python code, but it should probably only go in 2.5, > together with the patch #1390657 that relies on

Re: [Python-Dev] deque alternative (was: Linked lists)

On Dec 26, 2005, at 11:07 AM, Martin Blais wrote: >> Then there's the whole Python list with append() and pop(). It >> takes a >> method resolution and function call, but at least in Python 2.3, >> it is a >> hair faster... > > Josiah, that's beside the point, because it is not space-efficien

Re: [Python-Dev] NotImplemented reaching top-level

Hi, On Mon, Dec 26, 2005 at 02:40:38AM +1000, Nick Coghlan wrote: > That sounds like the right definition to me (I believe this behaviour is what > Raymond and Facundo were aiming for with the last round of updates to > Decimal). Done in patch #1390657. Although this patch passes all existing

Re: [Python-Dev] status of development documentation

Steve Holden wrote: > [EMAIL PROTECTED] wrote: > >>Steve> Alternatively, is there any mileage in trying to either get >>Steve> Sourceforge to provide Windows machines in the compile farm, or >>Steve> get Microsoft to provide more software fee to Windows testers? >> >>How about seeing i

Re: [Python-Dev] deque alternative (was: Linked lists)

On 12/25/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Tim Peters <[EMAIL PROTECTED]> wrote: > > Like Phillip Eby, I use 2-tuples for this when I feel the need > > (usually during a backtracking graph search, to keep track of paths > > back to the root in a space-efficient way), and am happy wi

Re: [Python-Dev] NotImplemented reaching top-level

Hi Brett, On Sun, Dec 25, 2005 at 11:55:11AM -0800, Brett Cannon wrote: > Maybe. Also realize we will have a chance to clean it up when Python > 3 comes around since the classic class stuff will be ripped out. That > way we might have a chance to streamline the code. For once, old-style classes

Re: [Python-Dev] NotImplemented reaching top-level

Armin Rigo <[EMAIL PROTECTED]> wrote: > Of course, speaking of a rewrite, PyPy does the "right thing" in > these two areas. Won't happen to CPython, though. There are too > much backward-compatibility issues with the PyTypeObject > structure; I think we're doomed with patching the bugs as they >

Re: [Python-Dev] deque alternative

Martin Blais wrote: > On 12/25/05, Christian Tismer <[EMAIL PROTECTED]> wrote: [is auto-dequeue too much magic?] > IMO it's a little bit too much magic. Plus, if you pass these > instances around e.g. between libraries, how could you determine with > certainty the usage patterns without analysin