On Tue, 29 Jul 2008 01:37:45 -0700, Carl Banks wrote: > On Jul 28, 8:15 pm, Steven D'Aprano <[EMAIL PROTECTED] > cybersource.com.au> wrote: >> On Mon, 28 Jul 2008 13:22:37 -0700, Carl Banks wrote: >> > On Jul 28, 10:00 am, Steven D'Aprano <[EMAIL PROTECTED] >> > cybersource.com.au> wrote: >> >> Cutting to the crux of the discussion... >> >> >> On Sun, 27 Jul 2008 23:45:26 -0700, Carl Banks wrote: >> >> > I want something where "if x" will do but a simple explicit test >> >> > won't. >> >> >> Explicit tests aren't simple unless you know what type x is. If x >> >> could be of any type, you can't write a simple test. Does x have a >> >> length? Is it a number? Maybe it's a fixed-length circular length, >> >> and the length is non-zero even when it's empty? Who knows? How many >> >> cases do you need to consider? >> >> > Use case, please. I'm asking for code, not arguments. Please give >> > me a piece of code where you can write "if x" that works but a simple >> > explicit test won't. >> >> I gave you a piece of code, actual code from one of my own projects. If >> you wouldn't accept that evidence then, why would you accept it now? > > I would accept as "evidence" something that satisfies my criteria, which > your example did not: it could have easily (and more robustly) been > written with a simple explicit test.
Only at the cost of completely ignoring the functional requirements and changing the API. In other words: you ignore my code, and invent your own imaginary code that does something completely different, then say that this imaginary code is better. And I question your assertion that a "simple explicit test" is more robust. Where's your evidence for that? > I am looking for one that can't. If you are writing code that needs to do the right thing with arbitrary types, then your so-called "simple explicit tests" simply can't work. If your code isn't expected to deal with arbitrary types, then you've got an excellent chance that it will work, because you know what types to expect. Until somebody passes a type that you didn't expect, and your code fails because it makes assumptions about the object. If you know that you only get lists, then "if len(x)!=0" is a perfectly good test (apart from being longer to type, harder to read, and slower to execute than "if x"). It will work so long as you only get objects where a length of zero is equivalent to being false. That's a good assumption to make, but it is an *unnecessary* assumption. Any reasonable object you get will know if it is false/nothing or true/something, so why make any assumptions? Just ask the object. It knows. > You keep bringing up this notion of "more complex with no benefit", > which I'm simply not interested in talking about that at this time, and > I won't respond to any of your points. Of course not. > I am seeking the answer to one > question: whether "if x" can usefully do something a simple explicit > test can't. "if x" is completely type agnostic. You can pass an object of any type to it, and it will work. (Excluding objects with buggy methods, naturally.) Try doing that with one of your so-called "simple explicit tests". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
