No :), go ahead! 2006/9/26, Oleg Broytmann <[EMAIL PROTECTED]>: > Hello! I am going to return to this discussion. I'd like to raise an > exception in __nonzero__(). Any argument against this? > > On Fri, May 19, 2006 at 12:41:11PM -0500, Ian Bicking wrote: > > Oleg Broytmann wrote: > > >On Fri, May 19, 2006 at 10:12:23AM -0500, Ian Bicking wrote: > > > > > >>It inherits __nonzero__ already (so SelectResults are always true), but > > >>does not implement __len__. Like I said, I really dislike those very > > >>few instances where you might encounter objects you can't test an object > > >>for truth, so I'm not very positive about that resolution. But I don't > > >>know, that's really the only way to keep people from introducing bugs > > >>into their code, since it's so natural (but probably incorrect) to test > > >>a SelectResult for truthfulness. > > > > > > > > > We have to choose among the following possibilities: > > > > > >1) implement __nonzero__() via count() and warn users that it's slow; > > >2) completely forbid __nonzero__() by raising an exception; > > >3) allow users to choose; write some classes that a user use to choose the > > > desired behavior. > > > > 1) No one will see our warning, unless we actually make it a warning, > > which is annoying and might as well be an exception IMHO. > > > > 2) Also annoying. You have to do more explicit tests then, like "is > > None" to avoid triggering __nonzero__. > > > > 3) I hate choice, then no one knows what someone else's code is going to > > be doing, help is harder to provide, etc. > > > > > > I'm leaning toward 2, like: > > > > def __nonzero__(self): > > raise NotImplementedError( > > "To test if a SelectResult will produce any items, use > > list(result) or result.count()") > > > > > > I'm not sure if it's a big backward compatibility problem, as I suspect > > it will reveal as many bugs as it does correct code that won't work. > > The only nuisance will be a place where people expect None, 0, and/or > > other false items, and are using the current behavior to distinguish > > those from SelectResult. That seems uncommon. If they just expect > > None, replace it with "is None". If they expect None or empty > > containers (like []), then treating SelectResult like a boolean is > > probably an outstanding bug. > > > > > > -- > > Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ [EMAIL PROTECTED] > Programmers don't die, they just GOSUB without RETURN. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > sqlobject-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss >
-- Michel Thadeu Sabchuk Curitiba - Brasil ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ sqlobject-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
