Re: [Python-Dev] deque alternative

[Christian Tismer]

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 analysing the entire codebase?  I
> think the user has to be involved.

Well, I would treat a list as a special case of dequeue.
Dequeues are made of a chain of list pieces. ATM they are
all equally sized. But turning a list into a dequeue like
structure at some point in the future can be done in many
ways. One way would be to embrace the list into the dequeue
structure without any copying involved, if a smooth transition
is crucial.
Passing the object between libraries gives me no problem.
We just track usage a little and even convert back to a list
if it seems appropriate. I think this can be cheap and elegant.
The question is less about implementation, but if we want this
to be explicitly more versatile, documenting it like
"""lists can be efficiently extended at both ends. Dependent on
the usage pattern, the implementation is free to choose a more
compact representation""".

> A problem I see now is that there is no way for me to
> indicate--whether there currently exists or not an appropriate data
> type with the desired characteristic-- whether I want an array (Python
> list) or a real list, both of which are really, really basic
> fundamental kinds of data structures with very different complexity
> characteristics.  The source code I write does not carry this
> information and therefore if in the future it would become available
> there won't be an easy way to convert code to take advantage of this. 
> This choice, is being made in the programmer's head, but the
> distinction blurred in the source code because lists are just not
> there.

I don't think your code has to decide about this. The power lies
in the fact that you don't specify that, but just use the list
in a different way. We do this in the PyPy implementation;
right now it is true that we have a static analysis, but a JIT
is to come, and I'm pretty sure it will try to use an array
until something gets used like a list.
No concrete layout available, yet.

...

> Also, there is something incredibly elegant and simple and compact
> about the cons cell, maybe all we need is a good simple cons cell type
> and a nice interface on it, so you get both single-linked lists and
> trees at the same time...

Tuples are fine for cons cells, and if your usage pattern
indicates that we can optimize, why should you use an extra
data type? You already said what you want, by the way you use
it. Extra-specification would be redundant, wouldn't it? :-)

ciao - chris
-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Neil Schemenauer]

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
> show up.

This is definitely something that should be cleaned up for Python
3k.

> Looking up in the language reference, I see no mention of NotImplemented
> in the page about __add__, __radd__, etc.  I guess it's a documentation
> bug as well, isn't it?  The current code base tries to implement the
> following behavior: Returning NotImplemented from any of the binary
> special methods (__xxx__, __rxxx__, __ixxx__) makes Python proceed as if
> the method was not defined in the first place.
>
> If we agree on this, I could propose a doc fix, a test, and appropriate
> bug fixes.

I believe that's correct.

  Neil

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Armin Rigo]

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 are not to blame here: it's only about the
oldest aspects of the PyTypeObject structure and substructures.


I-said-that-no-one-knows-this-code-any-more'ly yours,

Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin Blais]

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 with that.
>
> 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-efficient,
the list is actually an dynamic array/vector, and I would expect an
efficient array implementation to grow exponentially.  One of the
reasons we're talking about lists is to avoid exactly this problem...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] status of development documentation

[Steve Holden]

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 if Microsoft has or will create a compile farm?
>>
> 
> I'll see what I can do ...
> 
Interestingly, David Murmann has developed a mechanism using NAnt 
(nant.sf.net) for building Python using the Microsoft free tools. He has 
a patch that he announced on c.l.py, so I encouraged him to post about 
it on python-dev if he's prepared to maintain it.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Armin Rigo]

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 tests plus the ones it adds,
there is a corner and untested case where it could potentially break
code.  Indeed, the only sane patch I could come up with makes
user-defined types fail to work with PySequence_Concat() and
PySequence_Repeat() -- details in the patch.  So I propose that we
clarify what these two functions really mean in term of the Python
language spec, instead of just in term of the CPython-specific sq_concat
and sq_repeat slots.  (BTW that's needed for PyPy/Jython/etc., too, to
give a reasonable meaning to the operator.concat() and operator.repeat()
built-ins.)

I propose the following definitions (which are mostly what the
docstrings already explain anyway):

* PySequence_Concat(a, b) and operator.concat(a, b) mean "a + b", with
  the difference that we check that both arguments appear to be
  sequences (as checked with operator.isSequenceType()).

* PySequence_Repeat(a, b) and operator.repeat(a, b) mean "a * b", where
  "a" is checked to be a sequence and "b" is an integer.  Some bounds
  can be enforced on "b" -- for CPython, it means that it must fit in a
  C int.

The idea is to extend PySequence_Concat() and PySequence_Repeat() to
match the above definitions precisely, which means that for objects not
defining sq_repeat or sq_concat but still appearing to be sequences,
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 it.


A bientot,

Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[James Y Knight]

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-efficient,
> the list is actually an dynamic array/vector, and I would expect an
> efficient array implementation to grow exponentially.  One of the
> reasons we're talking about lists is to avoid exactly this problem...

Okay, now *that* reason is a pretty crazy one. Consider what you're  
saying here.

A list made of cons cells takes at least two words per element. And  
that's if you have an efficient GC mechanism tuned for cons cells,  
like popular common lisps have. In python, a cons cell will take at  
least 8 words (gc_next, gc_prev, gc_refs, padding, ob_refcnt,  
ob_type, and finally, car, and cdr). So a list of 100 elements will  
take _at best_ 200 words, and in python, a ghastly 800 words. Plus,  
in python, the overhead per object in the pyobject memory allocation  
system, which I don't know how to quantify.

An array takes one word per element, plus some header overhead. In  
python, the header overhead will be the same as above, plus around 3  
more words, so around 9 words. So to store an array of 100 elements  
will take around 109 words. Now let's say python did overallocate by  
100%. Then the array would take up 209 words. But it doesn't  
overallocate that much. The real formula is:
new_allocated = (newsize >> 3) + (newsize < 9 ? 3 : 6) + newsize;

So, the list will generally be 1/8th of its size overallocated, or  
112 elements plus 9 words overhead is 121 words. Better than any cons- 
linked list could be, and *insanely better* than a cons-linked list  
would be in python.

James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Facundo Batista]

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

It'd be good to know if this will be applied for the next version
2.4.x or will wait until 2.4.5, for me to search a workaround in
Decimal or not (really don't know if I can find a solution here).

Thank you!

.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Peters]

[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 Carlson]
>>> 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...

[Martin Blais]
>> Josiah, that's beside the point, because it is not space-efficient,
>> the list is actually an dynamic array/vector, and I would expect an
>> efficient array implementation to grow exponentially.  One of the
>> reasons we're talking about lists is to avoid exactly this problem...

[James Y Knight]
> Okay, now *that* reason is a pretty crazy one. Consider what you're
> saying here.

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:

kids[A] = [B]
kids[B] = [C]
kids[C] = [D]
...
kids[W] = [X]
kids[X] = [Y, Z]

A natural representation of the path from B back to the root is:

Bpath = B, (A, None)

and from C back to the root:

Cpath = C, Bpath

and from D back to the root:

Dpath = D, Cpath

...

and from X back to the root:

Xpath = X, Wpath

A "flat" list or tuple would certainly be more space-efficient up to
this point.  But when the graph branches, the 2-tuple representation
allows *sharing* the common path suffix (which may be very long!):

Ypath = Y, Xpath
and
Zpath = Z, Xpath

If there's an N-way branch, using 2-tuples allows recording the N new
paths back to the root with incremental memory burden N *
some_constant.  You can't do this kind of sharing with a flat list or
tuple, and the incremental memory burden at an N-way branch zooms to
(N + some_other_constant) * (the amount of memory needed to record the
path from the branch point back to the root), due to duplicating the
back-to-the-root info N times.   The potential memory saving from
using 2-tuples instead is unbounded.

...

> Plus, in python, the overhead per object in the pyobject memory allocation
> system, which I don't know how to quantify.

For objects requiring a number of bytes divisible by 8, a few percent
at worst.  The per-object space overhead in obmalloc consists entirely
of internal padding needed to reach a multiple of 8 bytes per
allocation unit, and that's 0 when the # of bytes needed is divisible
by 8.  The only obmalloc space overheads then are due to per-pool and
per-arena bookkeeping space, and those are small fractions of total
pool and arena sizes.

...

> So, the list will generally be 1/8th of its size overallocated, or
> 112 elements plus 9 words overhead is 121 words. Better than any cons-
> linked list could be, and *insanely better* than a cons-linked list
> would be in python.

You seem to be ignoring possiblities for sharing across lists, and
such sharing is natural in many graph algorithms.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ralf W. Grosse-Kunstleve]

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 has failed to start because MSVCP80.dll was
  not found. Re-installing the application may fix this problem.

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 the extensions?

A quick attempt to compile Python from scratch using Visual C++ 8.0
produced a python.exe, but it doesn't run (the debug / send report /
don't send report box pops up). Has someone tried this before?

Cheers,
Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Josiah Carlson]

> [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 Carlson]
> >>> 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...
> 
> [Martin Blais]
> >> Josiah, that's beside the point, because it is not space-efficient,
> >> the list is actually an dynamic array/vector, and I would expect an
> >> efficient array implementation to grow exponentially.  One of the
> >> reasons we're talking about lists is to avoid exactly this problem...
> 
> [James Y Knight]
> > Okay, now *that* reason is a pretty crazy one. Consider what you're
> > saying here.

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

Are you sure?

> A "flat" list or tuple would certainly be more space-efficient up to
> this point.  But when the graph branches, the 2-tuple representation
> allows *sharing* the common path suffix (which may be very long!):
...
> If there's an N-way branch, using 2-tuples allows recording the N new
> paths back to the root with incremental memory burden N *
> some_constant.  You can't do this kind of sharing with a flat list or
> tuple, and the incremental memory burden at an N-way branch zooms to
> (N + some_other_constant) * (the amount of memory needed to record the
> path from the branch point back to the root), due to duplicating the
> back-to-the-root info N times.   The potential memory saving from
> using 2-tuples instead is unbounded.

But one doesn't _need_ to use flat lists.  If one were to combine cons
cells with Python lists, you can get the space efficiency of lists with
the reusability of the desired cons cells (or tuples as the case may be).
How? (i, l), where i is the prefix of list l which is the desired
portion of whatever l represents.  You toss one of those anywhere in
your 'flat list', and you have your stored/saved path with a couple
dozen bytes. If you are not careful, you end up storing/saving paths
which would be stored more efficiently by copying the contents, but at
that point we are talking about a constant factor blowup, not the
(potentially) exponential blowup of storing all paths as copies, and we
can always copy to be more efficient if necessary.

I have personally used this trick to construct a union-find data
structure in which all unions are reversable regardless of find
operation. [1]


> > So, the list will generally be 1/8th of its size overallocated, or
> > 112 elements plus 9 words overhead is 121 words. Better than any cons-
> > linked list could be, and *insanely better* than a cons-linked list
> > would be in python.
> 
> You seem to be ignoring possiblities for sharing across lists, and
> such sharing is natural in many graph algorithms.

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 factor of ~4), and non-flat lists can be
smaller than cons cells in the rest of the cases.

 - Josiah

[1] If you remember, the ammortized running time of O(n) unions
and finds on a union-find data structure is O(n*alpha(n,n)), where
alpha(n,n) is never larger than 5 in practice.  The space overhead of
using non-flat lists as shared paths provides sufficient information to
offer reversable union operations in ammortized O(n*alpha(n,n)) space.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] that library reference, again

[Fredrik Lundh]

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 footsteps while running away screaming in 
> > fear *>
>
> really?

since everything that has people running in fear is worth investigating
further, I've spent a few hours putting together a first iteration of a
"python.org library reference to a javadoc-ish source format converter".

more info here:

http://effbot.org/zone/pythondoc-lib.htm

including goals, non-goals, and 2.5 megabytes of converted (but not
yet properly rendered) library pages.





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Peters]

...

[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 didn't mention that in the message of yours to
which Martin replied, and neither did James mention it in his message
to which I replied, and you shouldn't feel put upon that people
respond to what's actually written ;-)

[Tim, to James]
>> You seem to be ignoring possiblities for sharing across lists, and
>> such sharing is natural in many graph algorithms.

> Not necessarily so as I have pointed out above.

Gimme a break.  James didn't mention any such thing, and I was replying to him.

> 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 factor of ~4), and non-flat lists can be
> smaller than cons cells in the rest of the cases.

Yes.  Nevertheless, most people are going to use flats lists or pure
two-tuples in practice, simply because the coding for each is very
simple, and the idea that using flat lists "is better" was worth
opposing (because it isn't always true, and isn't even commonly true
in many graph algorithms, but was so strongly advanced in the message
to which I replied that using two-tuples instead was characterized as
"pretty crazy").
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Phillip J. Eby]

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 factor of ~4), and non-flat lists can be
>smaller than cons cells in the rest of the cases.

The reason I sometimes use 2-tuples as cons cells is that it's more 
convenient and/or intuitive than the alternatives for some recursive 
algorithms.  That's the practicality I'm interested in.  Copying a list or 
doing some other hokey-pokey data structure in such cases would just be 
annoying and make the code harder to follow.

Memory consumption and performance were never my reasons for 
cons-ing.  Some algorithms just read more cleanly that way.  In any case, 
regarding the usefulness of a built-in cons type, you're preaching to the 
choir here.  My whole point here is that when you *do* need a lispy list, 
two-item tuples are *the* One Obvious Way to do it in Python, because the 
existing syntax makes them effortless to use.  There's no need for a new 
built-in, 'cause what we already have works great.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 tool for the library reference...
> > >
> > > <* heavy clapping sound of my footsteps while running away screaming in 
> > > fear *>
> >
> > really?
>
> since everything that has people running in fear is worth investigating
> further, I've spent a few hours putting together a first iteration of a
> "python.org library reference to a javadoc-ish source format converter".
>
> more info here:
>
> http://effbot.org/zone/pythondoc-lib.htm
>
> including goals, non-goals, and 2.5 megabytes of converted (but not
> yet properly rendered) library pages.
>

Not specifically advocating the solution, but the markup looks
reasonable and easy to use.  Thanks for taking a stab at this, /F.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] A few questions about setobject

[Noam Raphael]

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 {
...
setentry *table;
setentry *(*lookup)(PySetObject *so, PyObject *key, long hash);
setentry smalltable[PySet_MINSIZE];
...
};

It seems to me that setentry and _setobject are defined for every file
that includes Python.h. In the Python C API, in the section about
include files, it is written that:
"All user visible names defined by Python.h (except those defined by
the included standard headers) have one of the prefixes "Py" or "_Py".
Names beginning with "_Py" are for internal use by the Python
implementation and should not be used by extension writers. Structure
member names do not have a reserved prefix."

Is this desirable? Even if it is, it seems that the second sentence
contradicts the first sentence. Perhaps the header file should stick
with writing "struct { long hash; PyObject *key; }" three times (or
define it in a macro and then undefine it), and the typedef be left to
the .c file?


2) The hash table used by sets uses a dummy element for deleted
entries. The implementation goes into the trouble of allocating it,
managing its reference count, and deallocating it at the end. What is
the reason for that? It seems to me that the only requirement of the
dummy element is that it shouldn't be a pointer to a valid PyObject,
and as such I would think that defining it like

int dummy_int;
PyObject *dummy = (PyObject *)(&dummy_int);

would be enough, and that it shouldn't be INCREFed or DECREFed every
time it is used. I think it should be ok because it's never used
really as a PyObject. Am I missing something? (Ok, I now thought that
maybe it's because some parts don't treat dummy elements specially.
But it seems to me that most parts do treat them specially, so perhaps
it would be better to make a few changes so that all parts will treat
them specially?)


3) The type of the result of a binary operator applied on a set and a
frozenset is the type of the left set. You are welcomed to ignore
this, but I just wanted to say that it seems to me better to make the
operator symmetric, and to return a frozenset only if both sets are
frozen.


If you think that these questions belong to c.l.py, then please say so
and I will go away.

Have a good day,
Noam
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin v. Löwis]

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 the extensions?

Can't check right now - but could it be that the standalone executables
get an extra copy of this library in their binary directory, as part
of the build process?

> A quick attempt to compile Python from scratch using Visual C++ 8.0
> produced a python.exe, but it doesn't run (the debug / send report /
> don't send report box pops up). Has someone tried this before?

Yes; a patch to fix this problem has been checked into the trunk
(but I have no plans for backporting it to the 2.4 branch, as 2.4
will be compiled with VC7.1 "forever" - i.e. until its final release).

Regards,
Martin

P.S. I currently also plan to build Python 2.5 with VC 7.1.
P.P.S. You do know that this configuration (extension compiled
with VS2005, Python compiled wit VS.NET2003) is not supported,
right?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Christian Tismer]

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 : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com