En Wed, 20 Aug 2008 21:49:14 -0300, [EMAIL PROTECTED] <[EMAIL PROTECTED]> escribió:
> On Aug 20, 10:59 am, Steven D'Aprano <[EMAIL PROTECTED] > cybersource.com.au> wrote: >> Oh goodie. Another programmer who goes out of his way to make it hard for >> other programmers, by destroying duck-typing. > > Remember kids: personal attacks are cruise control for cool. > > So this was a simplification - most of the asserts I've written don't > actually use isinstance, partly because typing isinstance takes too > long. The point is to create a barricade so that when something goes > wrong, you get an assertion error against the code you wrote, not an > exception against doing something like > > print("blah blah %s" % message) > > where message turns out to be None. This is simply a way to make > debugging a more pleasant experience (quite valuable IMHO since > debugging is inherently difficult and can be quite aggravating). Here > is a sampling: > > assert statelt.tag == 'stat' > assert len(path) > 0 and path[0] == '/' > assert self.__expr != None > > So here asserts are used to made distinctions that are more fine- > grained than type. I think you missed the point. All of those look like program logic verification, and that's fine. But using assert to check user-supplied data is wrong (here "user" may be another programmer if you're developing a library). Assertions may be turned off at runtime. > If you look at the history of the EAFP concept in Python, then you see > that it comes from Alex Martelli's Python in a Nutshell around pages > 113-114. Mmm, I think it's older than that. > I don't think the code examples make the case for EAFP very > well (not that I know what EAFP is in the first place, given that it > is barely explained. Ok, so you don't know what it is, but dislike it anyway? > I interpret it as "wrap questionable stuff in try/ > except blocks"), and in any case there is practically no support for > using EAFP as the dominant error-handling paradigm. Uh? I think that using try/except IS the "dominant error-handling paradigm" and that's just EAFP. > Martelli's posts in support of EAFP are heavily skewed towards a > multithreaded scenario and avoiding race conditions. IMHO, letting > locking and race condition concerns dictate your error-handling > paradigm is a case of the tail wagging the dog, especially when there > are alternatives to this particular tar pit: pipes or a shared nothing > architecture. There are race conditions since multiprogramming existed, around '70, and I'm afraid they'll stay for a long time... -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list