On 18 March 2015 at 09:56, Victor Stinner <victor.stin...@gmail.com> wrote:
> Hi, > > 2015-03-18 10:31 GMT+01:00 Martin Teichmann <martin.teichm...@gmail.com>: > > I'm currently porting code to use asyncio. I realized that queue.Queue > > and asyncio.Queue are very similar, which helps porting a lot, just > > one little detail: the exceptions raised by queue.Queue are called > > Empty and Full, while in asyncio the are called QueueEmpty and > > QueueFull. Personally, I don't have a preference for either, but I > > think it would be cool if they were called the same, or actually even > > be the same. > > Yes, exceptions have a different name because the queue module only > contains queues, whereas asyncio is a large package which contains a > lot of various classes: subprocesses, sockets, pipes, etc. "Full" > would be confusing (pipe full? stream buffer full? etc.), "QueueFull" > is more explicit for asyncio. > For what it's worth, if Full vs QueueFull ambiguity matters that much, then the same would apply to exceptions like ValueError. We don't need ParseFloatError when parsing floats, and IntParsingError when parsing ints. They both raise ValueError. Why is this not a problem? Because we programmers understand what an exception means within a given context. Likewise, I don't see any problem with having a single Full for any queue-like object to raise. The context (surrounding code) disambiguates what it means. Just my 2 cents. -- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert
