[Python-Dev] FIFO data structure?

[Agthorr]

On Thu, Apr 24, 2003 at 12:35:39AM -0400, Tim Peters wrote:
> I'm sorry I had to let this thread drop.  I had lots of time to type on the
> weekend, and on Monday because I took that day off from work sick.  My time
> is gone now, though.

Quite alright; I understand entirely.  I appreciate your responding
now :-)

> That is, for many apps, the first-in part of FIFO isn't needed, and a stack
> of work is just as good.  I'm not sure it wouldn't be just as good for your
> simulation app, either!

It might be.  When I originally wrote my simulation-dispatcher, it
needed to work with a small FIFO Queue.  I'm currently using it for a
different project where a large stack would work fine.  There's a good
chance that sometime in the future I'll need the large FIFO, though.

> People aren't "supposed to" muck with private names, and a single underscore
> at the front is a convention for saying "please don't muck with
> this".

I've been thinking about what the "right way" for the Queue to expose
it's interface would be.  It doesn't seem quite right for those
functions to be "public" names either; since they should never
actually be called directly by a user program.  Is there a convention
for member functions that are meant to be overridden, but not
(externally) called?

> I don't believe you made a strong enough case to break code that cheats,
> though:  the code as it is now is obviously correct at first glance.  The
> best that can be said for the much hairier circular-buffer business is that
> it's not obviously incorrect at first glance, and Python isn't immune to
> that ongoing maintenacne is more expensive than initial development.  I also
> think your use of (presumably many) thousands of Queue items is unusual.  A
> subclass may be welcome, and doc clarifications would certainly be
> welcome.

That's fair.  My other primary programming language is C, where the
standard libraries tend to be tightly optimized for performance.
Hence, my expectations tend to be biased in that direction.  That
doesn't mean that my expectations are the right way to do things
though ;)

"Premature optimization is the root of much evil"

> There aren't enough volunteers to review patches, and "Guido's team" doesn't
> spend work hours on Python anymore except as it happens to intersect with
> important Zope needs, so I'm afraid it may sit there forever.  Talking about
> it on Python-Dev was/is a good thing.  If you haven't already, you should
> devour the developer material at:
> 
>     http://www.python.org/dev/

I have, indeed, already devoured it.  :)

> Right now we're trying to conserve our "spare time" for resolving issues
> necessary to release 2.3b1 on Friday, so it's hard to keep a conversation
> going.

Okay, in that case I'll drop the Queue issue for now, and revisit the
thread on heaps.  That's something I feel needs to be done right for
2.3, or a bunch of user code will come to depend on the heap
implementation rather than the heap interface.

> Don't let any of this discourage you!  To become a Python developer requires
> an almost supernatural love of discouragement -- you'll know what I mean
> when you meet any of us <wink>.

Thanks :)

-- Agthorr