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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4