On Sat, Apr 14, 2001 at 07:59:16PM -0500, Guido van Rossum wrote: > [Tim] > > [..] I've never had, or been able to picture, a case where having a > > module object in an incomplete and unknown state is actually of use. > > OTOH, I've certainly burned my share of time recovering from that > > importing a broken module only fails the first time. It's like Python > > only raised an exception the first time somebody tried to open a > > particular non-existent file for reading, but the second time it > > returned a file object that may or may not fail in use, and may or may > > not work correctly when it doesn't fail, depending on what you do with > > it. > Maybe. Wouldn't the right place for the half-broken, import-failed module be in the traceback object ? In fact, isn't it already *in* the traceback object ? :) > It could be that the deep reason is mostly that the > implementation doesn't have the information available to decide what > to delete. Deep magic can be added. Deep magic should be added, IMHO, unless ... > I'll think about this over the weekend. I know people have tried to > convince me of changing this before, and I've tried to listen, but > I've never changed it, so I guess there must be a good reason. It's > worth trying to remember what it is! ... you come up with a real reason for it to be as it is ;) Happy-easter-for-those-of-you-with-permanent-'net-connections-*snif*-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
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