On Thu, 2012-06-28 at 03:01 -0400, Zdenek Pavlas wrote: > > This is so the failure handler can change it, right? > > Yep > > > And I assume the exceptions aren't in a singleton or something > > weird, so if the handler calls urlgrabber it won't overwrite previous data? > > It's a subclass of IOError so there's some magic in it, > but instances are independent and errno attribute is r/w. > One possible surprise I know of is: > > >>> e=URLGrabError(1, "Foo") > >>> e.errno=2 > >>> e.errno==2 > True > >>> e > URLGrabError(1, 'Foo') > > ..since str() uses original e.args tuple.
Ugh. That is inherited from IOError. Which implies that core python devs. think IOError should be r/o. > > to know if it can/should change the exception data. > > if e.errno==14 and e.code==503: e.errno=-1 # retry > > I'd put something like that in the callback, > that's probably specific/safe enough. > > > ACK unless you can think of a better way :). > > First idea was overriding the errcode with callback's > return value, unless it's None. Currently it's ignored > and callbacks return None, but we can't be sure. > r/w errno seems much better (atm). We could maybe test the return value and if it's a URLGrabError() then use that ... maybe slightly nicer. Just hacking the exception is probably going to be safe though. Upto you. _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
