Re: Boolean tests [was Re: Attack a sacred Python Cow]
Erik Max Francis wrote:
Antoon Pardon wrote:
[responding to me]
Maybe I'm going to be pedantic here, but I fear that your code won't
work with matrices. The problem is that multiplication is not
commutative with matrices. This means that matrices have two divisions
a right
and a left division. A far as I know the "/" operator usaly implements
the left division while solving is done by using a right division.
So your code will probably fail when applied to matrices.
Your remarks are correct as far as they go, but..
You're right in your general point, but usually division between
matrices isn't defined at all because of this ambiguity. However the
general point can still exist between `solveLeft` and `solveRight`
functions which do something along the lines of a*b**-1 and a**-1*b. A
single `solve`, of course, would choose one of these, and syntactically
it might be quite reasonable to define matrix division that does one of
these and have a single `solve` function that accomplishes it.
Therefore, the general point about polymorphism still stands.
as Eric suggests, I was assuming that details would be defined to make
my example work. The context was the challenge to find an example
where, for instance, 'if x:' would work but something more specific like
'if x != 0:' would not. My abstract answer was "number-like class with
division that is not valid for the class's null object". The concrete
answer was an incomplete instantiation of that for matrices. Given the
critique, polynomial division might be a better example since polynomial
multiplication is commutative while both ()(if allowed) and (0,) as
polyomials might well be defined as != to numeric 0. I suspect there
are other algebra classes that work for this or other examples, but it
has been a loong time since I took abstract algebra.
Actually I sort of worked too hard ;-).
The decimal module breaks the transitivity of equality!
>>> import decimal as d
>>> z=d.Decimal('0.0')
>>> z==0
True
>>> z==0.0
False
>>> 0==0.0
True
So if someone wrote 'if x == 0.0:' instead of 'if not x:' (perhaps to
raise an exception with explanation for unusable input), the former
would not work.
tjr
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Antoon Pardon wrote: Maybe I'm going to be pedantic here, but I fear that your code won't work with matrices. The problem is that multiplication is not commutative with matrices. This means that matrices have two divisions a right and a left division. A far as I know the "/" operator usaly implements the left division while solving is done by using a right division. So your code will probably fail when applied to matrices. You're right in your general point, but usually division between matrices isn't defined at all because of this ambiguity. However the general point can still exist between `solveLeft` and `solveRight` functions which do something along the lines of a*b**-1 and a**-1*b. A single `solve`, of course, would choose one of these, and syntactically it might be quite reasonable to define matrix division that does one of these and have a single `solve` function that accomplishes it. Therefore, the general point about polymorphism still stands. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis It is human nature to think wisely and act foolishly. -- Anatole France -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On 2008-08-01, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Nevertheless, I think this is probably the best example of the
>> enhanced polymorphism of "if x" yet. I'm kind of surprised no one
>> came up with it.)
>
> I think of Python code as 'generic' rather than 'polymorphic'. I am not
> sure if that is a real difference or not, since I am a bit fuzzy on the
> meaning of 'polymorphic' in this context.
>
> The generality of 'if x:' depends on the context. If x is defined as a
> number by doc or previous code (or possibly even by subsequent code),
> then 'if x:' is equivalent to 'if x != 0:'. At this point, it is a
> stylistic argument which to use.
>
> But here is an example where 'if x:' is more generic.
>
> def solve(a,b):
> 'a and b such that b/a exists'
> if a:
>return a/b
> else:
>raise ValueError('a not invertible, cannot solve'
>
> Now suppose we have a matrix class (2x2 for simplicity and realism).
> Its __bool__ (3.0) method implements 'is non-singular'. As written
> above, solve(mat,vec) works (with compatible mat and vec sizes), but it
> would not with 'if a != 0:'.
>
> Of course, the issue goes away by not looking before the leap:
>
> def solve(a,b):
> return a/b
> # let callers deal with exceptions
> or
> try:
> return a/b
> except...
># raise customized error
Maybe I'm going to be pedantic here, but I fear that your code won't
work with matrices. The problem is that multiplication is not
commutative with matrices. This means that matrices have two divisions a right
and a left division. A far as I know the "/" operator usaly implements
the left division while solving is done by using a right division.
So your code will probably fail when applied to matrices.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
On Jul 31, 6:15 pm, Paul McGuire <[EMAIL PROTECTED]> wrote: > On Jul 28, 12:15 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > > > > > > > On 28 Jul., 06:42, "Russ P." <[EMAIL PROTECTED]> wrote: > > > > On Jul 27, 8:58 pm, castironpi <[EMAIL PROTECTED]> wrote: > > > > > On Jul 27, 2:39 pm, Bruno Desthuilliers > > > > > <[EMAIL PROTECTED]> wrote: > > > > > Derek Martin a écrit : > > > > > > It's bad programming, but the world is full of bad programmers, and > > > > > > we > > > > > > don't always have the choice not to use their code. Isn't one of > > > > > > Python's goals to minimize opportunities for bad programming? > > > > > > Nope. That's Java's goal. Python's goals are to maximize opportunities > > > > > for good programming, which is quite different. > > > > Oh, gosh, that is so clever. What a bunch of crap. > > > > > +1 QOTW > > > > Do you realize what an insult that is to everyone else who has posted > > > here in the past week? > > > Nothing glues a community together so well as a common enemy. Or even > > better: two enemies i.e. Perl and Java in Pythons case. On the other > > hand, some enemies have to be ignored or declared to be not an enemy > > ( Ruby ), although oneself is clearly an enemy for them. The same > > antisymmetry holds for Python and Java. Java is an enemy for Python > > but Python is not worth for Java to be an enemy as long as it can be > > ignored. C++ and Java are enemies for each other. Same holds for Java > > and C#.- Hide quoted text - > > > - Show quoted text - > > Help... being... sucked into... black hole... inside a... Klein... > bottle...- Hide quoted text - > > - Show quoted text - ... which is inside... the black hole... -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
On Aug 3, 9:29 am, Michele Simionato <[EMAIL PROTECTED]> wrote: > On Jul 28, 8:46 pm, "Russ P." <[EMAIL PROTECTED]> wrote: > > > Letting "self" (or whatever the first argument was) be implied in > > ".cat" does absolutely *NOTHING* to change the internal workings of > > the Python interpreter. It's a very simple idea that you insist on > > making complicated. As I said, I could write a pre-processor myself to > > implement it in less than a day. > > I implemented such a pre-processor 6+ years ago and I am absolutely > sure > I was not to first one to reinvent this particular wheel. I have found the relevant thread: http://groups.google.com/group/comp.lang.python/browse_frm/thread6a7dd33dc287481f/3210d0be45113c23?hl=en&lnk=gst&=simionato+no+self#3210d0be45113c23 See also the comment by Alex Martelli. M.S. -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
On Jul 28, 8:46 pm, "Russ P." <[EMAIL PROTECTED]> wrote: > Letting "self" (or whatever the first argument was) be implied in > ".cat" does absolutely *NOTHING* to change the internal workings of > the Python interpreter. It's a very simple idea that you insist on > making complicated. As I said, I could write a pre-processor myself to > implement it in less than a day. I implemented such a pre-processor 6+ years ago and I am absolutely sure I was not to first one to reinvent this particular wheel. But now I have grown up and I am happy with self, because sometimes it can be named cls, mcl, obj or anything else, and I take advantage of this fact in my code. self is more readable than a dot and there is no point in making a special case for it. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Aug 1, 4:45 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > On Aug 1, 3:36 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > > In general, asking code to apply across numeric, container, and other > > classes is asking too much. Python code can be generic only within > > protocol/interface categories such as number-like, sortable, and > > iterable. But making tests too specific can unnecessarily prevent even > > that. > > At some point we have to throw our hands up and realize that if we're > working with custom classes with varying degrees of nonconformance, > there is nothing we can do that's safe. And I want to make clear I'm not trying to downplay your example here. The example you gave me definitely fits the criteria of being a useful "if x" that can't be replaced by a simple explicit test, at least after my alteration to a vector example. It's a concern when you write code that breaks realistic custom classes, but really concerning when it breaks built-in classes. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Aug 1, 4:45 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Aug 1, 3:36 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>
>
> > > Nevertheless, I think this is probably the best example of the
> > > enhanced polymorphism of "if x" yet. I'm kind of surprised no one
> > > came up with it.)
>
> > I think of Python code as 'generic' rather than 'polymorphic'. I am not
> > sure if that is a real difference or not, since I am a bit fuzzy on the
> > meaning of 'polymorphic' in this context.
>
> > The generality of 'if x:' depends on the context. If x is defined as a
> > number by doc or previous code (or possibly even by subsequent code),
> > then 'if x:' is equivalent to 'if x != 0:'. At this point, it is a
> > stylistic argument which to use.
>
> > But here is an example where 'if x:' is more generic.
>
> > def solve(a,b):
> > 'a and b such that b/a exists'
> > if a:
> >return a/b
> > else:
> >raise ValueError('a not invertible, cannot solve'
>
> > Now suppose we have a matrix class (2x2 for simplicity and realism).
> > Its __bool__ (3.0) method implements 'is non-singular'. As written
> > above, solve(mat,vec) works (with compatible mat and vec sizes), but it
> > would not with 'if a != 0:'.
>
> I see what you're saying, even though this example turns out to be
> pretty bad in practice.
>
> (Practically speaking, you hardly ever write code for both matrices
> and scalars, because the optimal way for matrices would be convoluted
> and opaque for scalars, though scalars can sometimes be fed into
> matrix code as a degenerate case. Also, checking the condition of the
> matrix by calculating and comparing the determinant to zero is like
> comparing float equality without a tolerance, only much, much worse.)
>
> But instead of a matrix, take a vector (which has a better chance of
> being used in code designed for scalars) and define a zero-length
> vector as false, and that could be a good example.
>
> > In general, asking code to apply across numeric, container, and other
> > classes is asking too much. Python code can be generic only within
> > protocol/interface categories such as number-like, sortable, and
> > iterable. But making tests too specific can unnecessarily prevent even
> > that.
>
> At some point we have to throw our hands up and realize that if we're
> working with custom classes with varying degrees of nonconformance,
> there is nothing we can do that's safe.
>
> > > Something versus nothing is a useless concept most of the time, but
> > > occasionally finds use in human interaction cases such as printing.
>
> > It is sometimes useful within categories of classes, as in my solve example.
>
> I'm going to say no.
>
> Let's take your matrix example: you defined singularity to be false,
> but singularity can't reasonably be mapped to the concept of nothing.
> For "nothing" I would think you'd want a 0x0 matrix. Something vs
> nothing also implies that all objects should have a boolean value.
> So, assuming boolean is connected to a matrices singularity, what
> should be the boolean value of non-square matrices?
>
> No, I'm going to have to disagree very strongly with this.
> Nonzeroness is useful. Emptiness is useful. Singularity a kind of
> useful. Nothing and something are vague, ill-defined, ad hoc concepts
> that mean nothing to a computer. Have you ever seen an algorithm that
> says "if x is something"?
>
> Something and nothing do seem to come into play occasionally in that,
> when interacting with humans (be it the user or programmer), it
> sometimes--not nearly always--makes sense to treat nonzero and empty
> in the same way. But there's no particular reason to apply the
> concepts of something and nothing beyond this pragmatic use.
>
> Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Aug 1, 3:36 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > Nevertheless, I think this is probably the best example of the
> > enhanced polymorphism of "if x" yet. I'm kind of surprised no one
> > came up with it.)
>
> I think of Python code as 'generic' rather than 'polymorphic'. I am not
> sure if that is a real difference or not, since I am a bit fuzzy on the
> meaning of 'polymorphic' in this context.
>
> The generality of 'if x:' depends on the context. If x is defined as a
> number by doc or previous code (or possibly even by subsequent code),
> then 'if x:' is equivalent to 'if x != 0:'. At this point, it is a
> stylistic argument which to use.
>
> But here is an example where 'if x:' is more generic.
>
> def solve(a,b):
> 'a and b such that b/a exists'
> if a:
>return a/b
> else:
>raise ValueError('a not invertible, cannot solve'
>
> Now suppose we have a matrix class (2x2 for simplicity and realism).
> Its __bool__ (3.0) method implements 'is non-singular'. As written
> above, solve(mat,vec) works (with compatible mat and vec sizes), but it
> would not with 'if a != 0:'.
I see what you're saying, even though this example turns out to be
pretty bad in practice.
(Practically speaking, you hardly ever write code for both matrices
and scalars, because the optimal way for matrices would be convoluted
and opaque for scalars, though scalars can sometimes be fed into
matrix code as a degenerate case. Also, checking the condition of the
matrix by calculating and comparing the determinant to zero is like
comparing float equality without a tolerance, only much, much worse.)
But instead of a matrix, take a vector (which has a better chance of
being used in code designed for scalars) and define a zero-length
vector as false, and that could be a good example.
> In general, asking code to apply across numeric, container, and other
> classes is asking too much. Python code can be generic only within
> protocol/interface categories such as number-like, sortable, and
> iterable. But making tests too specific can unnecessarily prevent even
> that.
At some point we have to throw our hands up and realize that if we're
working with custom classes with varying degrees of nonconformance,
there is nothing we can do that's safe.
> > Something versus nothing is a useless concept most of the time, but
> > occasionally finds use in human interaction cases such as printing.
>
> It is sometimes useful within categories of classes, as in my solve example.
I'm going to say no.
Let's take your matrix example: you defined singularity to be false,
but singularity can't reasonably be mapped to the concept of nothing.
For "nothing" I would think you'd want a 0x0 matrix. Something vs
nothing also implies that all objects should have a boolean value.
So, assuming boolean is connected to a matrices singularity, what
should be the boolean value of non-square matrices?
No, I'm going to have to disagree very strongly with this.
Nonzeroness is useful. Emptiness is useful. Singularity a kind of
useful. Nothing and something are vague, ill-defined, ad hoc concepts
that mean nothing to a computer. Have you ever seen an algorithm that
says "if x is something"?
Something and nothing do seem to come into play occasionally in that,
when interacting with humans (be it the user or programmer), it
sometimes--not nearly always--makes sense to treat nonzero and empty
in the same way. But there's no particular reason to apply the
concepts of something and nothing beyond this pragmatic use.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Aug 1, 8:49 am, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: Carl Banks wrote: On Jul 31, 11:44 pm, Carl Banks <[EMAIL PROTECTED]> wrote: [snip excellent explanation of why it's hard to for "if x" to be extensively polymorphic] By the way, one thing I forgot to mention is Matt Fitzgibbons' filter example. As I said, it's hard to write code that works for both numeric and container types because they share so few methods. However, sometimes you don't know ahead of time what methods are used! When you're doing functional programming you might pass in a method that calls the appropriate method, like so: def apply_if_true(func,x): if x: func(x) I find myself doing things like this surprisingly often. All you've done is move the decision as to what function is applied to x elsewhere. Like a factory, for example. I could see using something like this where func prepares object x to be inserted into a database, and you want to make sure x is meaningful first. def add_to_db(prep_func, x): if x: entry = prep_func(x) add_to_db(entry) 'if x' strikes me as better for this case because you might want to accept a non-empty list (or some other objects) but reject non-empty lists. 'if x is None' would not work. It still may be susceptible to the empty iterator problem, depending on what prep_func does. What if what you consider to be "meaningful" doesn't happen to coincide with what Python considers to be "something". For instance, what if being non-negative is what makes an integer meaningful? You can't use "if x" for that. What if any list, including an empty one, is meaningful, but you want to indicate the possibility of an unmeaningful value by passing None? You can't use "if x" for that. So, you might address this issue by doing something like this: def add_to_db(prep_func, is_meaningful, x): if is_meaningful(x): entry = prep_func(x) add_to_db(entry But if you do that, what has the polymorphism of "if x" gained you? The thing it gained for you before is not having to pass in a condition: whether x was a sequence, number, or whatever, the same condition could be used, and thus you avoided considerable complexity. But if you have to perform tests for which the implicit boolean doesn't work, that complexity has to be added to the code anyway. Of course. If a chunk of code already does what you want it to, then you can use it. Otherwise you have to do something different. I was just pointing out that 'if x' often does what I want it to. Sometimes it doesn't, so I do something different. That matters in the context of this discussion because it limits the usefulness of the polymorphism of "if x" for this functional idiom: "if x" only helps you if you have no need for tests that it can't handle. [snip] Carl Banks -- http://mail.python.org/mailman/listinfo/python-list By this argument, all code is limiting. Obviously, no code can do what it can't. We're not getting anywhere; it's past time to kill this one off. -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Nevertheless, I think this is probably the best example of the
enhanced polymorphism of "if x" yet. I'm kind of surprised no one
came up with it.)
I think of Python code as 'generic' rather than 'polymorphic'. I am not
sure if that is a real difference or not, since I am a bit fuzzy on the
meaning of 'polymorphic' in this context.
The generality of 'if x:' depends on the context. If x is defined as a
number by doc or previous code (or possibly even by subsequent code),
then 'if x:' is equivalent to 'if x != 0:'. At this point, it is a
stylistic argument which to use.
But here is an example where 'if x:' is more generic.
def solve(a,b):
'a and b such that b/a exists'
if a:
return a/b
else:
raise ValueError('a not invertible, cannot solve'
Now suppose we have a matrix class (2x2 for simplicity and realism).
Its __bool__ (3.0) method implements 'is non-singular'. As written
above, solve(mat,vec) works (with compatible mat and vec sizes), but it
would not with 'if a != 0:'.
Of course, the issue goes away by not looking before the leap:
def solve(a,b):
return a/b
# let callers deal with exceptions
or
try:
return a/b
except...
# raise customized error
In general, the ability to take advantage of "if x" polymorphism
across numeric, container, and other types depends on the something/
nothing dichotomy to be applicable.
Numbers and sequences are both sortable with the same algorithm if it is
written to be generic. However, 0 is nothing special when sorting, so
'if x:' would not be used.
All collections are (or should be) iterable. But a boolean test is not
part of the current iteration protocol. One might want to test whether
the iterable starts with anything before setting things up, but that
either exclude most iterators or requires wrapping them in a lookahead
class with a __bool__ method.
In general, asking code to apply across numeric, container, and other
classes is asking too much. Python code can be generic only within
protocol/interface categories such as number-like, sortable, and
iterable. But making tests too specific can unnecessarily prevent even
that.
> Something versus nothing is a useless concept most of the time, but
> occasionally finds use in human interaction cases such as printing.
It is sometimes useful within categories of classes, as in my solve example.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Aug 1, 8:49 am, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > On Jul 31, 11:44 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > > [snip excellent explanation of why it's hard to for "if x" to be > > extensively polymorphic] > > > By the way, one thing I forgot to mention is Matt Fitzgibbons' filter > > example. > > > As I said, it's hard to write code that works for both numeric and > > container types because they share so few methods. However, sometimes > > you don't know ahead of time what methods are used! When you're doing > > functional programming you might pass in a method that calls the > > appropriate method, like so: > > > def apply_if_true(func,x): > > if x: > > func(x) > > I find myself doing things like this surprisingly often. All you've done > is move the decision as to what function is applied to x elsewhere. Like > a factory, for example. I could see using something like this where func > prepares object x to be inserted into a database, and you want to make > sure x is meaningful first. > > def add_to_db(prep_func, x): > if x: > entry = prep_func(x) > add_to_db(entry) > > 'if x' strikes me as better for this case because you might want to > accept a non-empty list (or some other objects) but reject non-empty > lists. 'if x is None' would not work. It still may be susceptible to the > empty iterator problem, depending on what prep_func does. What if what you consider to be "meaningful" doesn't happen to coincide with what Python considers to be "something". For instance, what if being non-negative is what makes an integer meaningful? You can't use "if x" for that. What if any list, including an empty one, is meaningful, but you want to indicate the possibility of an unmeaningful value by passing None? You can't use "if x" for that. So, you might address this issue by doing something like this: def add_to_db(prep_func, is_meaningful, x): if is_meaningful(x): entry = prep_func(x) add_to_db(entry But if you do that, what has the polymorphism of "if x" gained you? The thing it gained for you before is not having to pass in a condition: whether x was a sequence, number, or whatever, the same condition could be used, and thus you avoided considerable complexity. But if you have to perform tests for which the implicit boolean doesn't work, that complexity has to be added to the code anyway. That matters in the context of this discussion because it limits the usefulness of the polymorphism of "if x" for this functional idiom: "if x" only helps you if you have no need for tests that it can't handle. [snip] Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On 2008-08-01, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> On 2008-08-01, Erik Max Francis <[EMAIL PROTECTED]> wrote: >>> Antoon Pardon wrote: >>> I now have the following question for people who argue that "if x" is more polymorphic. I could subclass list, so that instances of this new sequence would always behave as true, even if they are empty. I could then rewrite my loop as follows: while 1: extra = produce() if not extra: break for el in extra: adjust_with(el) calculate() Is this second loop now more polymorphic as the first? >>> It's more confusing since you've changed the standard behavior of a >>> standard type, which doesn't really have anything to do with >>> polymorphism. It's more confusing, if that's a benefit. >> >> So you accept my point that "if x" can be less polymorphic >> and in fact can be more confusing than a more specific test. >> > > I think your example is more related to a trap with polymorphism in > general rather than an argument against 'is x' specifically. I didn't want to argue against "if x". I just wanted to give a counter point to the argument that "if x" is more polymorphic. Whether more or less polymorphic is good or bad, depends on what kind of polymophism and circumstances. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Matthew Fitzgibbons wrote: 'if x' strikes me as better for this case because you might want to accept a non-empty list (or some other objects) but reject non-empty lists. 'if x is None' would not work. It still may be susceptible to the empty iterator problem, depending on what prep_func does. I mean reject empty lists. I need to be slower on hitting send. -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Jul 31, 11:44 pm, Carl Banks <[EMAIL PROTECTED]> wrote: [snip excellent explanation of why it's hard to for "if x" to be extensively polymorphic] By the way, one thing I forgot to mention is Matt Fitzgibbons' filter example. As I said, it's hard to write code that works for both numeric and container types because they share so few methods. However, sometimes you don't know ahead of time what methods are used! When you're doing functional programming you might pass in a method that calls the appropriate method, like so: def apply_if_true(func,x): if x: func(x) I find myself doing things like this surprisingly often. All you've done is move the decision as to what function is applied to x elsewhere. Like a factory, for example. I could see using something like this where func prepares object x to be inserted into a database, and you want to make sure x is meaningful first. def add_to_db(prep_func, x): if x: entry = prep_func(x) add_to_db(entry) 'if x' strikes me as better for this case because you might want to accept a non-empty list (or some other objects) but reject non-empty lists. 'if x is None' would not work. It still may be susceptible to the empty iterator problem, depending on what prep_func does. The function f could use methods appropriate for ints when x is an int, and for lists when x is an int. I did downplay this, because frankly, not many programmers use functional methods this extensively. But one should also note that you could pass in the test as well: def apply_if_condition(func,cond,x): if cond(x): func(x) Thus this usage of "if x" arguably could be considered "replaceable with a simple explicit test". But in the interests of harmony I didn't push the point, and it really would have been stretching the spirit of what I was trying to prove. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list Are you using cond to (a) determine is x is a suitable type to pass to func, or (b) whether or not to call func, based on some other characteristics of x? If (a), I think using a condition is this way is a little goofy. Why not just allow func to decide is x is an acceptable argument? (b) is not really what we've been discussing, so I assume not. I would seriously consider refactoring cond outside the function anyway. -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Antoon Pardon wrote: On 2008-08-01, Erik Max Francis <[EMAIL PROTECTED]> wrote: Antoon Pardon wrote: I now have the following question for people who argue that "if x" is more polymorphic. I could subclass list, so that instances of this new sequence would always behave as true, even if they are empty. I could then rewrite my loop as follows: while 1: extra = produce() if not extra: break for el in extra: adjust_with(el) calculate() Is this second loop now more polymorphic as the first? It's more confusing since you've changed the standard behavior of a standard type, which doesn't really have anything to do with polymorphism. It's more confusing, if that's a benefit. So you accept my point that "if x" can be less polymorphic and in fact can be more confusing than a more specific test. I think your example is more related to a trap with polymorphism in general rather than an argument against 'is x' specifically. Any time you override a method, you have an opportunity to change the behavior in unexpected ways. Especially in languages like Python that don't do type checking. For example, you write a __cmp__ method like this: class ReallyBadPractice(object): def __cmp__(self, other): return -cmp(self, other) Of course any code that does comparisons on this class is going to behave unexpectedly! -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On 2008-08-01, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: > >> I now have the following question for people who argue that "if x" >> is more polymorphic. I could subclass list, so that instances >> of this new sequence would always behave as true, even if they are >> empty. I could then rewrite my loop as follows: >> >> while 1: >> extra = produce() >> if not extra: >> break >> for el in extra: >> adjust_with(el) >> calculate() >> >> Is this second loop now more polymorphic as the first? > > It's more confusing since you've changed the standard behavior of a > standard type, which doesn't really have anything to do with > polymorphism. It's more confusing, if that's a benefit. So you accept my point that "if x" can be less polymorphic and in fact can be more confusing than a more specific test. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Antoon Pardon wrote: I now have the following question for people who argue that "if x" is more polymorphic. I could subclass list, so that instances of this new sequence would always behave as true, even if they are empty. I could then rewrite my loop as follows: while 1: extra = produce() if not extra: break for el in extra: adjust_with(el) calculate() Is this second loop now more polymorphic as the first? It's more confusing since you've changed the standard behavior of a standard type, which doesn't really have anything to do with polymorphism. It's more confusing, if that's a benefit. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis In a cosmic setting, vast and old, beyond ordinary human understanding, we are a little lonely. -- Carl Sagan, 1934-1996 -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On 2008-08-01, Carl Banks <[EMAIL PROTECTED]> wrote: > On Jul 31, 1:27 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: >> I'm really not sure where you're going with this or what you're trying >> to prove. "if x" is a duck-type test for a boolean value. Obviously if >> you know the type and want a more *specific* test, then you can use an >> explicit one. Any time you don't know or don't care about a more >> specific type than "something which probably is boolean true", or any >> time where you know the boolean semantics of the type and want to drop >> some typing, you can use "if x". The more specific test is what you'd >> use if you want more specific results. What's complicated about this >> idea? > > Many people trumpet that "if x" makes your code more polymorphic > whenever this comes up--in fact you just repeated the claim--without > ever considering how rarely this more extensive polymorphism comes up > in practice. I was calling them out to say "prove to me that it > actually happens". > > I believe it's very rare not to know enough about the expected type > that explicit tests won't work. We've uncovered a few examples of it > in this thread, but IMO we haven't uncovered any sort of broad, wide- > ranging use cases. I was reading this thread and was wondering about the following problem. I have a loop that continuously calculates something. I also have a producer that may produce extra input that can influence the calculations. The producer can also indicate the loop should finish. So the result of produce can be three things: 1) A not empty sequence; indicating available input. 2) An empty sequence; indicating no input available now. 3) None; indicating the end of the calculations. So the loop essentially looks like this: while 1: extra = produce() if extra is None: break for el in extra: adjust_with(el) calculate() I now have the following question for people who argue that "if x" is more polymorphic. I could subclass list, so that instances of this new sequence would always behave as true, even if they are empty. I could then rewrite my loop as follows: while 1: extra = produce() if not extra: break for el in extra: adjust_with(el) calculate() Is this second loop now more polymorphic as the first? Personnaly I would argue that the first loop with the more specific test is more polymorphic in this case, as it works with the standard sequence semantics of python; so the first loop will work with produce, producing any kind of sequence while the second loop will only work with produce producing a specific kind of sequence. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: If you recall, I agreed with his statement. Would you like to claim that I don't understand the fundamentals of Python? Since you've invented this connection out of nowhere, not particularly. I've never said anything about _anyone_ not understanding the fundamentals of Python, so you're just trying to make up controversy here. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis We all breathe the same air. We all cherish our children's future. And we are all mortal. -- John F. Kennedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 31, 11:44 pm, Carl Banks <[EMAIL PROTECTED]> wrote: [snip excellent explanation of why it's hard to for "if x" to be extensively polymorphic] By the way, one thing I forgot to mention is Matt Fitzgibbons' filter example. As I said, it's hard to write code that works for both numeric and container types because they share so few methods. However, sometimes you don't know ahead of time what methods are used! When you're doing functional programming you might pass in a method that calls the appropriate method, like so: def apply_if_true(func,x): if x: func(x) The function f could use methods appropriate for ints when x is an int, and for lists when x is an int. I did downplay this, because frankly, not many programmers use functional methods this extensively. But one should also note that you could pass in the test as well: def apply_if_condition(func,cond,x): if cond(x): func(x) Thus this usage of "if x" arguably could be considered "replaceable with a simple explicit test". But in the interests of harmony I didn't push the point, and it really would have been stretching the spirit of what I was trying to prove. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 10:05 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > On Jul 30, 1:07 am, Erik Max Francis <[EMAIL PROTECTED]> wrote: > >> Russ P. wrote: > >>> Oh, Lordy. I understand perfectly well how boolean tests, __len__, and > >>> __nonzero__ work in Python. It's very basic stuff. You can quit > >>> patronizing me (and Carl too, I'm sure). > >> You suggested a syntax for testing non-emptiness (`x is not empty`) > >> which indicated a profound misunderstanding of what the `is` operator does. > > >> You then acknowledged that there might be a problem because of the > >> implication if the `is` operator and weren't sure whether it would work > >> or not: > > > Oh, my. I wrote something like, "It would sure be nice to be able to > > write > > > if x is not empty: > > > because it reads like natural language. Immediately after I posted it, > > I thought, "oh, I'll bet some idiot takes that as a serious proposal." > > Sure enough, some idiot did just that almost immediately. > > Yes, all people are idiots for reading what you wrote, reading your > later realization that it was wrong, and taking both at face value. > I'll be sure never to make that mistake again! I thought it was obvious that he was paraphrasing. I also think that, among the people who took it literally, those who are not an ass would have accepted his explanation that he was paraphrasing it and moved on, rather than rubbing it in. If you recall, I agreed with his statement. Would you like to claim that I don't understand the fundamentals of Python? Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 31, 12:13 am, Ethan Furman <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > So I stand by the point I was trying to make: for your average day-to- > > day programming, the main benefit of "if x" is to save keystrokes. It > > doesn't help your code become more polymophic in practice. A little > > more polymorphic, yes. A lot, no. > > Hmmm... well, I see your point. Unfortunately, even though it feels > incorrect to me, I do not (yet) have the breadth and depth of Python > experience to come up with an example that would display such exquisite > polymorphism. It also seems to me that such an example would be > non-trivial in nature. Wrong on both counts. Let me give you a hint. Take integers and lists. Count how many methods the two types have in common. By my reckoning, they are: __add__, __iadd__, __mul__, _imul__, __str__, __repr__, and __nonzero__. Also there are __getattribute__ and __setattr__, but lists and ints share no common attributes. I don't think ints have any at all aside from the special methods. What this means is: any code that can work for both ints and lists must use only these methods (this is not quite correct, but mostly is). That eliminates probably 99.9% of code right off the bat. Then you have to consider that some code that does use only these attributes does something useful only for either ints or lists, not both. Take this simple example: def foil(a,b,c,d): return a*b + a*d + b*c + b*d This code works if a and c are both ints, or are both lists (while b and d would have to be ints). It does something useful for ints and other numeric types, but does it do anything useful for lists? Third, there are cases where you have code that works for both ints and lists, that does do something useful for both, but it makes no sense to apply "if x" to it. def print_if_true(x): if x: print x This little piece of code might actually come in handy here and there, but would it end up being used for numeric types a whole lot? It seems like if you have an empty list you might reasonably want to print nothing at all, but when you have a zero integer you usually want to print the zero. (However, you might reasonably want to print some object unless it's None. You could then use this one function to handle that case as well as the case with empty lists, instead of defining two functions, like so: print_if_not_empty(x): if len(x)!=0: print x print_if_not_None(x): if x is not None: print x But wait! What if you had a value that could be either an integer or None? You can't use the "if x" variant because x could be False. So you'd have to define the "if x is not None" variant anyway. I might use the "if x" variant in throwaway scripts, but for anything production I would prefer the explicit variants, partially because, as shown above, even when "if x" does rear it's polymoprhic head, it doesn't necessarily buy you much. Nevertheless, I think this is probably the best example of the enhanced polymorphism of "if x" yet. I'm kind of surprised no one came up with it.) In general, the ability to take advantage of "if x" polymorphism across numeric, container, and other types depends on the something/ nothing dichotomy to be applicable. Something versus nothing is a useless concept most of the time, but occasionally finds use in human interaction cases such as printing. So there you have it. This is why I didn't expect anyone to come up with a good example: you just don't have a lot to work with. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 31, 1:27 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > I'm really not sure where you're going with this or what you're trying > to prove. "if x" is a duck-type test for a boolean value. Obviously if > you know the type and want a more *specific* test, then you can use an > explicit one. Any time you don't know or don't care about a more > specific type than "something which probably is boolean true", or any > time where you know the boolean semantics of the type and want to drop > some typing, you can use "if x". The more specific test is what you'd > use if you want more specific results. What's complicated about this > idea? Many people trumpet that "if x" makes your code more polymorphic whenever this comes up--in fact you just repeated the claim--without ever considering how rarely this more extensive polymorphism comes up in practice. I was calling them out to say "prove to me that it actually happens". I believe it's very rare not to know enough about the expected type that explicit tests won't work. We've uncovered a few examples of it in this thread, but IMO we haven't uncovered any sort of broad, wide- ranging use cases. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Steven D'Aprano wrote:
>On Thu, 31 Jul 2008 22:01:48 +0100, Matthew Woodcraft wrote:
>> The point is that if you tell people that "if x" is the standard way to
>> check for emptiness, and also support a general principle along the
>> lines of "write your function using the interfaces you expect, and call
>> it using the object you have", you should expect to end up with bugs of
>> this sort.
> I'm not sure that an occasional performance hit justifies calling it a
> bug. I suppose you might come up with a scenario or two where it really
> is a problem, but then I'm also free to imagine scenarios where calling
> len(obj) takes a massive performance hit, or has irreversible side
> effects.
Of course performance problems can be bugs! And it was explicit in my
example that this was supposed to be such a case.
But here, have an example where it's a non-performance bug:
def load_widgets(self, widgets):
if not widgets:
raise ValueError("no widgets specified")
self._prepare_for_widgets()
for widget in widgets:
self._load_widget(widget)
self._is_widgetty = True
This way you can end up with an object in an invalid state.
>> I'm not a fan of len() for testing emptiness. But it would have been
>> better in this case, because it would have converted a hard-to-find
>> performance bug into an obvious exception.
> At the cost of wrongly raising a exception for perfectly good arguments,
> namely non-empty iterators.
Sure, which will be fixed when the code passing an iterator is first
tested, whether the iterator is empty or not. It's the errors which pass
silently that are most dangerous.
As I said, I'm not a fan of len() for testing emptiness. But "if x"
isn't good either. Often I end up rearranging things so I can get rid of
the explicit test altogether, but there can be a cost in readability.
I think any Python-like language would be better off with an explicit
way of asking 'is this container empty?'.
-M-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
On Jul 28, 12:15 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > On 28 Jul., 06:42, "Russ P." <[EMAIL PROTECTED]> wrote: > > > > > > > On Jul 27, 8:58 pm, castironpi <[EMAIL PROTECTED]> wrote: > > > > On Jul 27, 2:39 pm, Bruno Desthuilliers > > > > <[EMAIL PROTECTED]> wrote: > > > > Derek Martin a écrit : > > > > > It's bad programming, but the world is full of bad programmers, and we > > > > > don't always have the choice not to use their code. Isn't one of > > > > > Python's goals to minimize opportunities for bad programming? > > > > > Nope. That's Java's goal. Python's goals are to maximize opportunities > > > > for good programming, which is quite different. > > > Oh, gosh, that is so clever. What a bunch of crap. > > > > +1 QOTW > > > Do you realize what an insult that is to everyone else who has posted > > here in the past week? > > Nothing glues a community together so well as a common enemy. Or even > better: two enemies i.e. Perl and Java in Pythons case. On the other > hand, some enemies have to be ignored or declared to be not an enemy > ( Ruby ), although oneself is clearly an enemy for them. The same > antisymmetry holds for Python and Java. Java is an enemy for Python > but Python is not worth for Java to be an enemy as long as it can be > ignored. C++ and Java are enemies for each other. Same holds for Java > and C#.- Hide quoted text - > > - Show quoted text - Help... being... sucked into... black hole... inside a... Klein... bottle... -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Thu, 31 Jul 2008 22:01:48 +0100, Matthew Woodcraft wrote: > Steven D'Aprano wrote: >>On Wed, 30 Jul 2008 20:55:03 +0100, Matthew Woodcraft wrote: > >>> On the other hand, iterators provide a clear example of problems with >>> "if x": __nonzero__ for iterators (in general) returns True even if >>> they are 'empty'. > >> How do you propose telling whether an iterator is empty? That's a >> generic problem with any sort of lazy function. You don't know if it >> has finished unless you try grabbing data from it. > > Of course. > > The point is that if you tell people that "if x" is the standard way to > check for emptiness, and also support a general principle along the > lines of "write your function using the interfaces you expect, and call > it using the object you have", you should expect to end up with bugs of > this sort. I'm not sure that an occasional performance hit justifies calling it a bug. I suppose you might come up with a scenario or two where it really is a problem, but then I'm also free to imagine scenarios where calling len(obj) takes a massive performance hit, or has irreversible side effects. >>> For example, this function (which attempts to avoid making an >>> expensive call when not necessary) is buggy, but easy to write if >>> you've been taught that "if x" will work with any kind of object. >>> >>> def frob(widgets, power): >>> if widgets: >>> frobber = Frobber(power) # expensive call >>> for widget in widgets: >>> frobber.frob(widget) But note that the code still does the right thing even if widgets is empty. The only problem is that it needlessly calls Frobber. Frankly, that would have to be *really* expensive before I would even bother using the more complicated code. This is a good example of premature optimization. >> AFAIK there's no great solution to this problem. It's inherent in the >> way lazy functions work. Certainly you can't replace the call to "if >> widgets" with "if len(widgets)", because iterators don't have a length. > > I'm not a fan of len() for testing emptiness. But it would have been > better in this case, because it would have converted a hard-to-find > performance bug into an obvious exception. At the cost of wrongly raising a exception for perfectly good arguments, namely non-empty iterators. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Steven D'Aprano wrote: >On Wed, 30 Jul 2008 20:55:03 +0100, Matthew Woodcraft wrote: >> On the other hand, iterators provide a clear example of problems with >> "if x": __nonzero__ for iterators (in general) returns True even if they >> are 'empty'. > How do you propose telling whether an iterator is empty? > That's a generic problem with any sort of lazy function. You don't know > if it has finished unless you try grabbing data from it. Of course. The point is that if you tell people that "if x" is the standard way to check for emptiness, and also support a general principle along the lines of "write your function using the interfaces you expect, and call it using the object you have", you should expect to end up with bugs of this sort. >> For example, this function (which attempts to avoid making an expensive >> call when not necessary) is buggy, but easy to write if you've been >> taught that "if x" will work with any kind of object. >> >> def frob(widgets, power): >> if widgets: >> frobber = Frobber(power) # expensive call >> for widget in widgets: >> frobber.frob(widget) > AFAIK there's no great solution to this problem. It's inherent in the way > lazy functions work. Certainly you can't replace the call to "if widgets" > with "if len(widgets)", because iterators don't have a length. I'm not a fan of len() for testing emptiness. But it would have been better in this case, because it would have converted a hard-to-find performance bug into an obvious exception. >However, there is a good (but not great) solution: > >def frob(widgets, power): >widgets = iter(widgets) # in case widgets is a sequence >try: >first = widgets.next() >except StopIteration: ># empty iterator, nothing to do >return None >frobber = Frobber(power) # expensive call >frobber.frob(widget) >for widget in widgets: >frobber.frob(widget) I would use the following low-tech way: def frob(widgets, power): frobber = None for widget in widgets: if frobber is None: frobber = Frobber(power) frobber.frob(widget) -M- -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Matthew Fitzgibbons wrote:
Steven D'Aprano wrote:
On Wed, 30 Jul 2008 09:23:05 -0600, Matthew Fitzgibbons wrote:
If you're expecting a list (and only a list)
then your point makes sense. 'if x' can get you into trouble if you
_don't_ want its polymorphism.
"if x" is hardly unique in that way. If you're expecting a list, and
only a list, "len(x) != 0" will get you in trouble if somebody passes
a string or a dictionary. I don't see any reason why we should single
out "if x" as dangerous in the face of invalid types. With the
exception of the "is" and "is not" operators, nothing in Python is
guaranteed to work with any imaginable object. Even print can fail, if
the object's __str__ method raises an exception.
Although, if my function is expecting a list, my preference is to do:
if not isinstance(x, list):
raise SomeMeaningfulException()
# do stuff with the list
I put my type checking at the top of the function, so readers can
reference it easily.
And thus you break duck-typing and upset anybody who wants to pass a
sequence that doesn't inherit directly from list.
There are other (and arguably better, although more labour-intensive)
techniques for defensive programming that don't break duck-typing. You
can google for Look Before You Leap and Easier To Ask Forgiveness Than
Permission for more information. Alex Martelli has a fine recipe in
the Python Cookbook -- search for the recipe "Checking if an object
has the necessary attributes".
But in a nutshell, here's a toy example:
def spam(seq):
try:
seq.append
seq.extend
seq[0] = seq[0]
except Exception:
raise TypeError("argument isn't sufficiently sequence-like")
# No exceptions expected from here on
seq.append(seq[0])
seq.extend([1,2,3])
seq[0] = "spam"
Yes, I know it breaks duck typing, which is why I do it only very
rarely, and never with e.g. sequence types. If I use ifinstance for type
checking, it's because I need some _very_ specific class, almost always
one that I wrote. My more usual use case for ifinstance is to figure out
how to handle a particular object using introspection.
That said, your example is still helpful. It's a good approach, and I
should use it more often. Although I'd also lean toward hasattr and
iscallable and ordinary ifs instead of the try ... except where
possible. Depending on what you put in the try ... except, you risk
masking legit exceptions.
Ahhh, Programing. Where no rule of thumb seems to last five minutes.
-Matt
--
http://mail.python.org/mailman/listinfo/python-list
Where by ifinstance I mean isinstance and by iscallable I mean callable.
*hides*
-Matt
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Steven D'Aprano wrote: On Wed, 30 Jul 2008 09:23:05 -0600, Matthew Fitzgibbons wrote: If you're expecting a list (and only a list) then your point makes sense. 'if x' can get you into trouble if you _don't_ want its polymorphism. "if x" is hardly unique in that way. If you're expecting a list, and only a list, "len(x) != 0" will get you in trouble if somebody passes a string or a dictionary. I don't see any reason why we should single out "if x" as dangerous in the face of invalid types. With the exception of the "is" and "is not" operators, nothing in Python is guaranteed to work with any imaginable object. Even print can fail, if the object's __str__ method raises an exception. Forgot respond to this point. I heartily agree. :) I singled out 'if x' only because that's the specific example under scrutiny. I think you and I are pretty much in agreement. -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Steven D'Aprano wrote:
On Wed, 30 Jul 2008 09:23:05 -0600, Matthew Fitzgibbons wrote:
If you're expecting a list (and only a list)
then your point makes sense. 'if x' can get you into trouble if you
_don't_ want its polymorphism.
"if x" is hardly unique in that way. If you're expecting a list, and only
a list, "len(x) != 0" will get you in trouble if somebody passes a string
or a dictionary. I don't see any reason why we should single out "if x"
as dangerous in the face of invalid types. With the exception of the "is"
and "is not" operators, nothing in Python is guaranteed to work with any
imaginable object. Even print can fail, if the object's __str__ method
raises an exception.
Although, if my function is expecting a list, my preference is to do:
if not isinstance(x, list):
raise SomeMeaningfulException()
# do stuff with the list
I put my type checking at the top of the function, so readers can
reference it easily.
And thus you break duck-typing and upset anybody who wants to pass a
sequence that doesn't inherit directly from list.
There are other (and arguably better, although more labour-intensive)
techniques for defensive programming that don't break duck-typing. You
can google for Look Before You Leap and Easier To Ask Forgiveness Than
Permission for more information. Alex Martelli has a fine recipe in the
Python Cookbook -- search for the recipe "Checking if an object has the
necessary attributes".
But in a nutshell, here's a toy example:
def spam(seq):
try:
seq.append
seq.extend
seq[0] = seq[0]
except Exception:
raise TypeError("argument isn't sufficiently sequence-like")
# No exceptions expected from here on
seq.append(seq[0])
seq.extend([1,2,3])
seq[0] = "spam"
Yes, I know it breaks duck typing, which is why I do it only very
rarely, and never with e.g. sequence types. If I use ifinstance for type
checking, it's because I need some _very_ specific class, almost always
one that I wrote. My more usual use case for ifinstance is to figure out
how to handle a particular object using introspection.
That said, your example is still helpful. It's a good approach, and I
should use it more often. Although I'd also lean toward hasattr and
iscallable and ordinary ifs instead of the try ... except where
possible. Depending on what you put in the try ... except, you risk
masking legit exceptions.
Ahhh, Programing. Where no rule of thumb seems to last five minutes.
-Matt
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Tue, Jul 29, 2008 at 3:37 AM, Carl Banks <[EMAIL PROTECTED]> 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. I am looking for one that > can't. > > 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. I am seeking the answer to > one question: whether "if x" can usefully do something a simple > explicit test can't. Everyone already knows that "if x" requires > fewer keystrokes and parses to fewer nodes. > I'm really not sure where you're going with this or what you're trying to prove. "if x" is a duck-type test for a boolean value. Obviously if you know the type and want a more *specific* test, then you can use an explicit one. Any time you don't know or don't care about a more specific type than "something which probably is boolean true", or any time where you know the boolean semantics of the type and want to drop some typing, you can use "if x". The more specific test is what you'd use if you want more specific results. What's complicated about this idea? -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 31, 7:08 am, "Russ P." <[EMAIL PROTECTED]> wrote: > On Jul 30, 10:43 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > > > > > Russ P. wrote: > > > On Jul 30, 9:27 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > > >> You're sure going on about a distinction without a difference for a guy > > >> who childishly likes to call other people names. A reasonable person > > >> would have long ago moved on instead of blaming others for not > > >> immediately intuiting your thoughts, rather than straightforwardly > > >> reading your words. Which, by the way, includes at least three people > > >> other than myself. > > > >> But I'll bet the mindless namecalling is really working out for you. > > >> Go, team, go! > > > > You earned the "childish name calling" by acting like a child -- with > > > your petty little game of trying to show that I don't understand a > > > basic concept in Python. As I said, your initial misunderstanding, > > > while silly, was at least forgivable. But your insistence on repeating > > > it time after time is not. It is truly pathetic. > > > Sis, boom, rah rah rah! > > > You're kind of skipping over the point where three other people had the > > same misunderstanding about your original statement and correction, so > > Another whopper, but who's counting? > > > maybe the reader is not the problem but rather the writer, but hey, > > don't let that get in the way of a good public shitfit. > > > You're winning! > > And you're a professional of some sort? Man, I can't even imagine > working in an environment with people like you. I guess I'm pretty > lucky to work with real professionals who don't play petty little > games like the one you played here -- and are still playing. Go ahead, > have the last word, loser -- then get lost. You understand this is usenet, right? Where we can all read the entire thread? So trying to spin the situation just doesn't work? Just checking... Iain -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 10:43 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > On Jul 30, 9:27 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > >> You're sure going on about a distinction without a difference for a guy > >> who childishly likes to call other people names. A reasonable person > >> would have long ago moved on instead of blaming others for not > >> immediately intuiting your thoughts, rather than straightforwardly > >> reading your words. Which, by the way, includes at least three people > >> other than myself. > > >> But I'll bet the mindless namecalling is really working out for you. > >> Go, team, go! > > > You earned the "childish name calling" by acting like a child -- with > > your petty little game of trying to show that I don't understand a > > basic concept in Python. As I said, your initial misunderstanding, > > while silly, was at least forgivable. But your insistence on repeating > > it time after time is not. It is truly pathetic. > > Sis, boom, rah rah rah! > > You're kind of skipping over the point where three other people had the > same misunderstanding about your original statement and correction, so Another whopper, but who's counting? > maybe the reader is not the problem but rather the writer, but hey, > don't let that get in the way of a good public shitfit. > > You're winning! And you're a professional of some sort? Man, I can't even imagine working in an environment with people like you. I guess I'm pretty lucky to work with real professionals who don't play petty little games like the one you played here -- and are still playing. Go ahead, have the last word, loser -- then get lost. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: On Jul 30, 9:27 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: You're sure going on about a distinction without a difference for a guy who childishly likes to call other people names. A reasonable person would have long ago moved on instead of blaming others for not immediately intuiting your thoughts, rather than straightforwardly reading your words. Which, by the way, includes at least three people other than myself. But I'll bet the mindless namecalling is really working out for you. Go, team, go! You earned the "childish name calling" by acting like a child -- with your petty little game of trying to show that I don't understand a basic concept in Python. As I said, your initial misunderstanding, while silly, was at least forgivable. But your insistence on repeating it time after time is not. It is truly pathetic. Sis, boom, rah rah rah! You're kind of skipping over the point where three other people had the same misunderstanding about your original statement and correction, so maybe the reader is not the problem but rather the writer, but hey, don't let that get in the way of a good public shitfit. You're winning! -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis I am not a Virginian, but an American. -- Patrick Henry -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 9:27 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > I don't know if you can read minds, but you seem to have a lot of > > trouble reading words. > > > Can you read "it would be nice to be able to write ..."? Can you > > understand what it means? Can you understand that it does *not* mean, > > "one *should* be able to write ..."? > > You're sure going on about a distinction without a difference for a guy > who childishly likes to call other people names. A reasonable person > would have long ago moved on instead of blaming others for not > immediately intuiting your thoughts, rather than straightforwardly > reading your words. Which, by the way, includes at least three people > other than myself. > > But I'll bet the mindless namecalling is really working out for you. > Go, team, go! You earned the "childish name calling" by acting like a child -- with your petty little game of trying to show that I don't understand a basic concept in Python. As I said, your initial misunderstanding, while silly, was at least forgivable. But your insistence on repeating it time after time is not. It is truly pathetic. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Ethan Furman wrote: > If that's really what you want, go join Dave Parker and Flaming Thunder. Best recommendation in this thread to date :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: I don't know if you can read minds, but you seem to have a lot of trouble reading words. Can you read "it would be nice to be able to write ..."? Can you understand what it means? Can you understand that it does *not* mean, "one *should* be able to write ..."? You're sure going on about a distinction without a difference for a guy who childishly likes to call other people names. A reasonable person would have long ago moved on instead of blaming others for not immediately intuiting your thoughts, rather than straightforwardly reading your words. Which, by the way, includes at least three people other than myself. But I'll bet the mindless namecalling is really working out for you. Go, team, go! -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis You are my martyr / I'm a vestige of a revolution -- Lamya -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 8:24 pm, "Russ P." <[EMAIL PROTECTED]> wrote: > On Jul 30, 8:03 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > > > Russ P. wrote: > > > The reason I wrote that "it would be nice to be able to write" > > > > if x is not empty: > > > > is that it reads naturally. It was not an actual proposal, and the > > > fact that you took it as such was *your* mistake. > > ... > > > Now read carefully: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! Let > > > me repeat that for you: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! > > > Did you get that, idiot? > > > So people who can read words but not minds are idiots. Go get 'em, tiger! > > I don't know if you can read minds, but you seem to have a lot of > trouble reading words. > > Can you read "it would be nice to be able to write ..."? Can you > understand what it means? Can you understand that it does *not* mean, > "one *should* be able to write ..."? > > The really significant question here is why I waste my valuable time > with pedants like you. Folks, I'm sorry for being so harsh here. But this guy keeps insisting that I dispayed a "fundamental lack of understanding" of the correct usage of "is" in Python. If that were true, I would have gladly admitted it and dropped the matter. But it is completely false. The simple fact is that I fully understood how "is" works in Python from the first time I read about it -- as I'm sure most others here did too. It just gets my goat that someone would latch onto some whimsical suggestion I wrote to try to prove otherwise. He did not need to play that silly little game, and he could have easily avoided my insults had he not played it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: [snippers] The reason I wrote that "it would be nice to be able to write" if x is not empty: is that it reads naturally. [and more snippers] Reads naturally? For whom? "Readability counts" does not mean "make it sound like english as much as possible". There are good reasons for not having computer languages written in human language. If that's really what you want, go join Dave Parker and Flaming Thunder. Or write that preprocessor that someone keeps yammering about and have it take code the way you want to write it and convert it to actual Python. Would be an interesting experiment, anyway. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Thu, 31 Jul 2008 02:41:08 +, Steven D'Aprano wrote: > On Wed, 30 Jul 2008 09:23:05 -0600, Matthew Fitzgibbons wrote: ... >> Although, if my function is expecting a list, my preference is to do: >> >> if not isinstance(x, list): >> raise SomeMeaningfulException() >> # do stuff with the list >> >> I put my type checking at the top of the function, so readers can >> reference it easily. > > And thus you break duck-typing and upset anybody who wants to pass a > sequence that doesn't inherit directly from list. Correction: delete "directly" from the above. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 8:03 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > The reason I wrote that "it would be nice to be able to write" > > > if x is not empty: > > > is that it reads naturally. It was not an actual proposal, and the > > fact that you took it as such was *your* mistake. > ... > > Now read carefully: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! Let > > me repeat that for you: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! > > Did you get that, idiot? > > So people who can read words but not minds are idiots. Go get 'em, tiger! I don't know if you can read minds, but you seem to have a lot of trouble reading words. Can you read "it would be nice to be able to write ..."? Can you understand what it means? Can you understand that it does *not* mean, "one *should* be able to write ..."? The really significant question here is why I waste my valuable time with pedants like you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Jul 30, 4:49 am, Ethan Furman <[EMAIL PROTECTED]> wrote: Even for those that did realize, and in fact hoped that that is what you were attempting to accomplish, I was not attempting to accomplish what you think I was. I was looking for it, but I didn't want to see it. I didn't expect to see it. I wanted to show that "if x" doesn't have the polymorphic advantage people mindlessly claim it does by posing the challenge and having people fail to meet it, and for the most part the examples that met the challenge were for minor usages. Ok, someone wrote a filter that truly benefits from polymorphism of "if x" against very different types, but really, these use cases aren't all that common. It's not like it's an everyday thing for you to write "if x" instead of "if x!=0", and that it actually saves you from having to rewrite the condition because later you decided to use a list. Actually, I use this construction a lot. But everybody has their own style, and I'm certainly not going to tell you yours is wrong. One of the fellows that works for me *loves* the (result if false, result if true)[condition] style of immediate if's -- it's one of the first things he learned about when studying Python, and he grins every time he talks about it; *I* know it's not the best way to do it, and that it has it's own set of gotchas -- so I made sure he was also aware of them, and uses them where and when they won't blow up in our faces. So I stand by the point I was trying to make: for your average day-to- day programming, the main benefit of "if x" is to save keystrokes. It doesn't help your code become more polymophic in practice. A little more polymorphic, yes. A lot, no. [snippitysnipsnip] Carl Banks Hmmm... well, I see your point. Unfortunately, even though it feels incorrect to me, I do not (yet) have the breadth and depth of Python experience to come up with an example that would display such exquisite polymorphism. It also seems to me that such an example would be non-trivial in nature. Perhaps starting a new thread with this challenge, and adequate time (couple weeks at least, I would think) would net you the smoking gun you were after. At any rate, from my point of view, I like it. I like the visual clarity and simplistic nature of "if x" -- it tells me "if x is something", and I trust myself enough to know what I can do with the something that is x. I also expect anyone else passing me a something to know it has the appropriate interface to work with my code. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: The reason I wrote that "it would be nice to be able to write" if x is not empty: is that it reads naturally. It was not an actual proposal, and the fact that you took it as such was *your* mistake. ... Now read carefully: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! Let me repeat that for you: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! Did you get that, idiot? So people who can read words but not minds are idiots. Go get 'em, tiger! -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis If you turned right / You turned left / Or if you just walked out ahead -- Anggun -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Wed, 30 Jul 2008 20:55:03 +0100, Matthew Woodcraft wrote: > On the other hand, iterators provide a clear example of problems with > "if x": __nonzero__ for iterators (in general) returns True even if they > are 'empty'. How do you propose telling whether an iterator is empty? That's a generic problem with any sort of lazy function. You don't know if it has finished unless you try grabbing data from it. > For example, this function (which attempts to avoid making an expensive > call when not necessary) is buggy, but easy to write if you've been > taught that "if x" will work with any kind of object. > > def frob(widgets, power): > if widgets: > frobber = Frobber(power) # expensive call > for widget in widgets: > frobber.frob(widget) AFAIK there's no great solution to this problem. It's inherent in the way lazy functions work. Certainly you can't replace the call to "if widgets" with "if len(widgets)", because iterators don't have a length. However, there is a good (but not great) solution: def frob(widgets, power): widgets = iter(widgets) # in case widgets is a sequence try: first = widgets.next() except StopIteration: # empty iterator, nothing to do return None frobber = Frobber(power) # expensive call frobber.frob(widget) for widget in widgets: frobber.frob(widget) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Wed, 30 Jul 2008 09:23:05 -0600, Matthew Fitzgibbons wrote:
> If you're expecting a list (and only a list)
> then your point makes sense. 'if x' can get you into trouble if you
> _don't_ want its polymorphism.
"if x" is hardly unique in that way. If you're expecting a list, and only
a list, "len(x) != 0" will get you in trouble if somebody passes a string
or a dictionary. I don't see any reason why we should single out "if x"
as dangerous in the face of invalid types. With the exception of the "is"
and "is not" operators, nothing in Python is guaranteed to work with any
imaginable object. Even print can fail, if the object's __str__ method
raises an exception.
> Although, if my function is expecting a list, my preference is to do:
>
> if not isinstance(x, list):
> raise SomeMeaningfulException()
> # do stuff with the list
>
> I put my type checking at the top of the function, so readers can
> reference it easily.
And thus you break duck-typing and upset anybody who wants to pass a
sequence that doesn't inherit directly from list.
There are other (and arguably better, although more labour-intensive)
techniques for defensive programming that don't break duck-typing. You
can google for Look Before You Leap and Easier To Ask Forgiveness Than
Permission for more information. Alex Martelli has a fine recipe in the
Python Cookbook -- search for the recipe "Checking if an object has the
necessary attributes".
But in a nutshell, here's a toy example:
def spam(seq):
try:
seq.append
seq.extend
seq[0] = seq[0]
except Exception:
raise TypeError("argument isn't sufficiently sequence-like")
# No exceptions expected from here on
seq.append(seq[0])
seq.extend([1,2,3])
seq[0] = "spam"
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 7:05 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > On Jul 30, 1:07 am, Erik Max Francis <[EMAIL PROTECTED]> wrote: > >> Russ P. wrote: > >>> Oh, Lordy. I understand perfectly well how boolean tests, __len__, and > >>> __nonzero__ work in Python. It's very basic stuff. You can quit > >>> patronizing me (and Carl too, I'm sure). > >> You suggested a syntax for testing non-emptiness (`x is not empty`) > >> which indicated a profound misunderstanding of what the `is` operator does. > > >> You then acknowledged that there might be a problem because of the > >> implication if the `is` operator and weren't sure whether it would work > >> or not: > > > Oh, my. I wrote something like, "It would sure be nice to be able to > > write > > > if x is not empty: > > > because it reads like natural language. Immediately after I posted it, > > I thought, "oh, I'll bet some idiot takes that as a serious proposal." > > Sure enough, some idiot did just that almost immediately. > > Yes, all people are idiots for reading what you wrote, reading your > later realization that it was wrong, and taking both at face value. > I'll be sure never to make that mistake again! > > > And he is > > still patronizing me for it. > > No, I'm not patronizing you for your initial misstatement. I'm mocking > you for your pathetic and transparent attempt to backpedal away from it. > Just give it up, already. > > -- > Erik Max Francis && [EMAIL PROTECTED] &&http://www.alcyone.com/max/ > San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis >Drifting from woman-who-tries misconstrued / Shifting to woman-wise > -- Lamya The reason I wrote that "it would be nice to be able to write" if x is not empty: is that it reads naturally. It was not an actual proposal, and the fact that you took it as such was *your* mistake. I can understand your misunderstanding one time, but you have now repeated it three times, despite my (unnecessary) explanations. One more time, and you graduate from idiot to moron. Having said that, the syntax I wrote *could* conceivably work IF all empty lists pointed to one empty list, just as all values set to None actually point to the same None. That is possible, but probably not a good idea. Now read carefully: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! Let me repeat that for you: I DID NOT CLAIM THAT THIS IS THE WAY TO DO IT! Did you get that, idiot? -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 1:50 am, Carl Banks <[EMAIL PROTECTED]> wrote: > On Jul 30, 1:58 am, "Russ P." <[EMAIL PROTECTED]> wrote: > > > > > On Jul 29, 10:33 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > > > > On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: > > > > Having said that, it would sure be nice to be able to write > > > > > if myList is not empty: > > > > > instead of > > > > > if len(myList) != 0: > > > > I can agree with this. > > > But I guess that could only work if there were only one empty list > > that represents all empty lists (as there is only one actual "None"). > > I don't know if that makes sense or not. > > I mean in general. I wouldn't spell it like that. I would prefer if > empty(x), with an __empty__ method. (And support __nonzero__ aka > __bool__ dropped completely.) > > Carl Banks An __empty__ method could return True for my social life, ha ha. Does __nonzero__ just mean __nonempty__? -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: On Jul 30, 1:07 am, Erik Max Francis <[EMAIL PROTECTED]> wrote: Russ P. wrote: Oh, Lordy. I understand perfectly well how boolean tests, __len__, and __nonzero__ work in Python. It's very basic stuff. You can quit patronizing me (and Carl too, I'm sure). You suggested a syntax for testing non-emptiness (`x is not empty`) which indicated a profound misunderstanding of what the `is` operator does. You then acknowledged that there might be a problem because of the implication if the `is` operator and weren't sure whether it would work or not: Oh, my. I wrote something like, "It would sure be nice to be able to write if x is not empty: because it reads like natural language. Immediately after I posted it, I thought, "oh, I'll bet some idiot takes that as a serious proposal." Sure enough, some idiot did just that almost immediately. Yes, all people are idiots for reading what you wrote, reading your later realization that it was wrong, and taking both at face value. I'll be sure never to make that mistake again! And he is still patronizing me for it. No, I'm not patronizing you for your initial misstatement. I'm mocking you for your pathetic and transparent attempt to backpedal away from it. Just give it up, already. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis Drifting from woman-who-tries misconstrued / Shifting to woman-wise -- Lamya -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 4:49 am, Ethan Furman <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > On Jul 29, 6:42 pm, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: > >> I don't have any postable code (it's in a half way state and I haven't > >> touched it for a while), but I'll see if I can't find the time to bang > >> something up to give you the gist. > > > I wouldn't bother at this point. I was looking to see if someone > > could come up with something to disprove my belief on the polymorphic > > uselessness of "if x" relative to explicit tests, and if (as I > > anticipated) they did not, I could claim that "if x" is really just a > > glorified keystroke saver. But I now realize that the failure of this > > bunch doesn't prove anything. I don't think most people even realize > > why answering the question I asked would demonstrate the usefulness of > > "if x". > > > Your example isn't exactly the smoking gun I was looking for, but I > > guess we'll have to admit that at least one usage will suffer for not > > having it. > > > Carl Banks > > Even for those that did realize, and in fact hoped that that is what you > were attempting to accomplish, I was not attempting to accomplish what you think I was. I was looking for it, but I didn't want to see it. I didn't expect to see it. I wanted to show that "if x" doesn't have the polymorphic advantage people mindlessly claim it does by posing the challenge and having people fail to meet it, and for the most part the examples that met the challenge were for minor usages. Ok, someone wrote a filter that truly benefits from polymorphism of "if x" against very different types, but really, these use cases aren't all that common. It's not like it's an everyday thing for you to write "if x" instead of "if x!=0", and that it actually saves you from having to rewrite the condition because later you decided to use a list. So I stand by the point I was trying to make: for your average day-to- day programming, the main benefit of "if x" is to save keystrokes. It doesn't help your code become more polymophic in practice. A little more polymorphic, yes. A lot, no. > it was still quite frustrating to see you > ignoring all the non-code, yet perfectly valid examples of why "if x" > was not only valid, but the most pythonic[1] way to get the task done. Pfft. The usage of "if x" might be Pythonic, but I think the best way is the way Java does it. > I think it would have been a better discussion if you had responded with > reasons why, and not just parroted the "show me the code!" line over and > over and over and ... It seemed as if you thought you were the > professor, impatiently trying to teach a class full of idiots by playing > the devil's advocate. I wasn't playing Devil's advocate, I was playing the Devil. That's why I did that. Sorry if it irritated people but I wasn't about to those things distract me. > I was sure hoping someone would get the actual > code example and post it, partly because I enjoy learning, but mostly > because it would (hopefully) shut you up and move the conversation > along. In fact, somebody did post some code about a custom matrix > class, where __len__ was useless, and still you kept on with... pah. I admit it! I downplay even successful examples because I just don't like implicit booleans. What can I say, I'm an optimist. I didn't see any custom matrix class, BTW. The only code I saw was Steven D'Aprano filter which he still apparently expects me to take his word for it that the alternative I proposed won't work, and Terry Reedy's empty-enabled iterator. Oh, also Heiko Wundram's integer set. > It's late, so before I say something stupid I'll finish this. My last > thought on the matter -- up until this thread I had looked forward to > your posts, Carl. I think you did more damage than good to yourself > with this stunt. Sorry, but I must go on a crusade every once in awhile, whatever damage it may cause my esteem. It's in my nature. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 3:56 am, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > I mean in general. I wouldn't spell it like that. I would prefer if > > empty(x), with an __empty__ method. (And support __nonzero__ aka > > __bool__ dropped completely.) > > So your argument is purely about style, then. You just wish it were > written differently. No, you misunderstand and/or misstate my position again. I realize I wasn't as clear as I could have been. First of all it's not my "argument": this is a tangent. There would be a built-in empty, which invokes __empty__, in the same way len invokes __len__. It would only be defined for container types. (Iterators could choose whether to define it and it would mean that the iterator is guaranteed stop on the next iteration. The iterator is free to read and store the item. If the iterator doesn't know whether it will stop, it must not define __empty__ or raise an exception in it.) It would become the One Obvious Way to test for emptiness. __nonzero__ would disappear and not be replaced with anything, and objects would not have implicit boolean conversion. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 11:07 am, Terry Reedy <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > That's not what I was asking for. I was asking for a use case for "if > > x" that can't be replaced by a simple explicit test. Your example > > didn't satisfy that. > > But I believe my example of an iterator with __bool__ but not with > __len__ does. And I believe I followed up to your post saying as much. :) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 1:07 am, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > Oh, Lordy. I understand perfectly well how boolean tests, __len__, and > > __nonzero__ work in Python. It's very basic stuff. You can quit > > patronizing me (and Carl too, I'm sure). > > You suggested a syntax for testing non-emptiness (`x is not empty`) > which indicated a profound misunderstanding of what the `is` operator does. > > You then acknowledged that there might be a problem because of the > implication if the `is` operator and weren't sure whether it would work > or not: Oh, my. I wrote something like, "It would sure be nice to be able to write if x is not empty: because it reads like natural language. Immediately after I posted it, I thought, "oh, I'll bet some idiot takes that as a serious proposal." Sure enough, some idiot did just that almost immediately. And he is still patronizing me for it. Hey, dude, if you think I ever had any doubt about what "is" means in Python, you are simply wrong. Completely wrong. Can you get that through your thick skull? One of the problems with this site is that you have pedants who like to show off their knowledge of the Python language. I suspect that many of these people know little more than the rules of programming in Python. They are like someone who thinks he is a writer because he knows how to use Microsoft Word, or someone who thinks he is a chess expert because he knows the rules for moving the pieces. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Terry Reedy <[EMAIL PROTECTED]> wrote: >Carl Banks wrote: >> That's not what I was asking for. I was asking for a use case for "if >> x" that can't be replaced by a simple explicit test. Your example >> didn't satisfy that. > But I believe my example of an iterator with __bool__ but not with > __len__ does. On the other hand, iterators provide a clear example of problems with "if x": __nonzero__ for iterators (in general) returns True even if they are 'empty'. For example, this function (which attempts to avoid making an expensive call when not necessary) is buggy, but easy to write if you've been taught that "if x" will work with any kind of object. def frob(widgets, power): if widgets: frobber = Frobber(power) # expensive call for widget in widgets: frobber.frob(widget) -M- -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Jul 29, 6:42 pm, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: I don't have any postable code (it's in a half way state and I haven't touched it for a while), but I'll see if I can't find the time to bang something up to give you the gist. I wouldn't bother at this point. I was looking to see if someone could come up with something to disprove my belief on the polymorphic uselessness of "if x" relative to explicit tests, and if (as I anticipated) they did not, I could claim that "if x" is really just a glorified keystroke saver. But I now realize that the failure of this bunch doesn't prove anything. I don't think most people even realize why answering the question I asked would demonstrate the usefulness of "if x". Your example isn't exactly the smoking gun I was looking for, but I guess we'll have to admit that at least one usage will suffer for not having it. Carl Banks Even for those that did realize, and in fact hoped that that is what you were attempting to accomplish, it was still quite frustrating to see you ignoring all the non-code, yet perfectly valid examples of why "if x" was not only valid, but the most pythonic[1] way to get the task done. I think it would have been a better discussion if you had responded with reasons why, and not just parroted the "show me the code!" line over and over and over and ... It seemed as if you thought you were the professor, impatiently trying to teach a class full of idiots by playing the devil's advocate. I was sure hoping someone would get the actual code example and post it, partly because I enjoy learning, but mostly because it would (hopefully) shut you up and move the conversation along. In fact, somebody did post some code about a custom matrix class, where __len__ was useless, and still you kept on with... pah. It's late, so before I say something stupid I'll finish this. My last thought on the matter -- up until this thread I had looked forward to your posts, Carl. I think you did more damage than good to yourself with this stunt. ~Ethan~ [1] by pythonic I mean using the features of the language that make sense. In this case, the __nonzero__ function to have the object in question tell us whether or not it's empty. This seems so basic (the __nonzero__ function, that is, and its purpose) -- do you really need code to prove it to yourself? -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Jul 29, 6:42 pm, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: Carl Banks wrote: Much like in Steven D'Aprano's example, still the only actual code snippet I've seen, it seems that this can easily be done with a simple explicit test by having all no-advance filters return None and testing with "if x is not None". So it doesn't pass my criterion of being not replaceable with simple explicit test. Maybe that's not workable for some reason. Perhaps if you'd post a code example that shows this, rather than just talking about it, you might be more persuasive. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list The no-advance filters have to return the object because I don't just forget about it; I evaluate whether I pass it to the next filter or drop it in a completely different queue for use in the next stage of the operation. True means 'I'm ready to move on to the next stage,' False means 'Do the filter thing some more.' I think I see what you're saying, and yeah I guess that could really take advantage of polymorphism between very different types. Furthermore, the argument that I should just change my API to make a 'simple test' work is not very convincing. I wasn't suggesting you change it: I was trying to ascertain whether it would have suffered much if you had written it with explicit tests in the first place, or if Python didn't even have magical booleans. Yes it would have suffered. I chose the implementation I did because it made the most sense to me and was the most flexible (a key requirement). Instead of cobbling together my own way, I used the way that Python gave me. Python doesn't have magic booleans. They are instead a very well-defined language mechanism that isn't perfect for every circumstance, but is pretty good for the most part. I wanted to do meaningful boolean tests on various objects, so I used the mechanism that my language gave me. The natural, obvious way for a filter to work is to pass through the data it operates on; why on Earth would it return None? I want to DO something with the data. In this case, make a decision about where to pass the data next. If you don't mind me asking: what do you do actually DO with a zero or empty list? Depends on exactly what the next stage is. Typically, zeros and empty lists are not meaningful for the next stage, so they get dropped then if they make it through. I don't want to restrict what gets passed through, though, because I could end up with several meaningful data types, making a simple test again impossible. So I pass everything through and let the next stage decide. In Java, to accomplish this I would have to do lots of introspection and value checking (adding more any time I came up with a new kind of input), or make a new kind of interface that gives me a method so I can do a 'simple test' (including wrappers for ints and arrays and anything else I decide to pass in down the road). But Python supports duck typing and gives me a handy __nonzero__ method; I can rebind __nonzero__ in my filters for my own classes, and ints and lists are handled how I want them to be by default. So why jump through hoops instead of just using 'if x'? Ah, so it's just happens to work. Still, just happening to work works. (shrug) Nonono. The point you seem to be missing is that 'if x' is very well defined. There is nothing magic or arbitrary about what it does. It works here and elsewhere because Python (a) chooses good default behavior (its treatment of lists and ints, etc) and (b) gives you a way, __nonzero__, to change the behavior to suit your needs. I don't have any postable code (it's in a half way state and I haven't touched it for a while), but I'll see if I can't find the time to bang something up to give you the gist. I wouldn't bother at this point. I was looking to see if someone could come up with something to disprove my belief on the polymorphic uselessness of "if x" relative to explicit tests, and if (as I anticipated) they did not, I could claim that "if x" is really just a glorified keystroke saver. But I now realize that the failure of this bunch doesn't prove anything. I don't think most people even realize why answering the question I asked would demonstrate the usefulness of "if x". Of course you don't _need_ to have 'if x'; after all, REAL programmers code in machine language. The whole point of a high-level language is to make life easier. Python is very dynamic and allows duck typing so that you can use these tools to do clever things that would otherwise be very difficult. It even gives you a handy polymorphic mechanism to do boolean tests, which my example illustrates. You asked for a use case for a polymorphic 'if x' that can't be easily replaced by a simple test. I gave one. Then you asked for a code sample, but now have dismissed my sample as not compelling without having seen it. But here it is anyway (attached). It's pret
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: On Jul 30, 12:03 am, Heiko Wundram <[EMAIL PROTECTED]> wrote: Am Mittwoch, 30. Juli 2008 08:30:48 schrieb Russ P.: On Jul 29, 11:09 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: I'm getting this sneaking suspicion that you guys are all putting us on. As I said in an earlier post, I realize that this would only work if there were only one copy of "empty" (as there is only one copy of "None"). I don't know off hand if that is feasible or not. You reply reeks of the kind of pedantic snobbishness that makes me sick. I can understand (and pretty much sympathise) that you get this kind of reply, simply because the point you and Carl Banks (formulated somewhat differently) put up has been answered again and again (in this thread), and I can only repeat it once more: __nonzero__(), i.e. the "cast" to boolean, is THE WAY to test whether a container is empty or not. Like this design decision, or don't like it, but the discussion is not going to go anywhere unless you concede that there is a (very explicit!) way to test for non-emptiness of a container already, and you're currently simply discussing about adding/using syntactic sugar (different means of expressing the test) to suit your own personal taste better. Anyway, check the documentation for __nonzero__(): if the object doesn't implement that, but implements __len__(), the interpreter "replaces" the __nonzero__() test by __len__()>0, so I guess someone in the design department must've seen it logical for the truth value of a container to express the test "len(x)>0" at some point in time to make this interpretation for the truth value of a container. There cannot be an argument about missing/misplaced functionality (that's what you make it sound like), if the functionality for doing what you want to do is there and you simply don't like the syntax, which I can somewhat relate to because style is a personal thing, even though I don't see either points made by you or Carl Banks, because implicit casting to bool is so common in pretty much every programming language to test for "truth" of an object, and IMHO it's completely logical to extend that idea to containers to mean empty/non-empty. Eric Max Francis tried to explain why your syntactic "enhancement" would come at a much greater price than its worth, and he's absolutely right in that, as it's an abuse of the "is" operator, but again, that's a somewhat different point. It changes nothing about the fact that all this discussion centers around something that is a non-point, but simply a matter of personal taste. -- Heiko Wundram Oh, Lordy. I understand perfectly well how boolean tests, __len__, and __nonzero__ work in Python. It's very basic stuff. You can quit patronizing me (and Carl too, I'm sure). The point that you seem to be missing, or refuse to acknowledge for some reason, is that "if x" can be mistakenly applied to any object when the programmer thinks that x is a list -- and the programmer will receive no feedback on the error. I have made errors like that, and I could have saved some time had I used an "empty" method that only applies to a list or other sequence. Is that an important issue? I don't know. I'm not claiming it is. But you cannot just sweep it away as nothing. -- http://mail.python.org/mailman/listinfo/python-list See, I can agree with this. If you're expecting a list (and only a list) then your point makes sense. 'if x' can get you into trouble if you _don't_ want its polymorphism. Although, if my function is expecting a list, my preference is to do: if not isinstance(x, list): raise SomeMeaningfulException() # do stuff with the list I put my type checking at the top of the function, so readers can reference it easily. However, Carl's point is that 'if x' is never preferable to the more verbose and slower "simple test". I do not agree with this. -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Jul 30, 1:58 am, "Russ P." <[EMAIL PROTECTED]> wrote: On Jul 29, 10:33 pm, Carl Banks <[EMAIL PROTECTED]> wrote: On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: Having said that, it would sure be nice to be able to write if myList is not empty: instead of if len(myList) != 0: I can agree with this. But I guess that could only work if there were only one empty list that represents all empty lists (as there is only one actual "None"). I don't know if that makes sense or not. I mean in general. I wouldn't spell it like that. I would prefer if empty(x), with an __empty__ method. (And support __nonzero__ aka __bool__ dropped completely.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list __nonzero__ is not only meaningful for sequence types. -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: That's not what I was asking for. I was asking for a use case for "if x" that can't be replaced by a simple explicit test. Your example didn't satisfy that. But I believe my example of an iterator with __bool__ but not with __len__ does. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Le Wednesday 30 July 2008 15:31:28 [EMAIL PROTECTED], vous avez écrit : > > > class Signal: > > > [...] > > > def dc_offset(self, amount): > > > if amount == 0: > > > return > > > self.samples = [sample + amount for sample in self.samples] > > > > This function is also wrong assuming that because amount compare to zero, > > it can be added to sample. > > Not quite. I'm assuming that if amount equals 0, then amount is some > scalar. In fact, only if that comparison fails will I get my > exception: since [] != 0, it will then try to add sample + [], which > will raise TypeError. > > > If you want to make type checking just check the type or convert your > > parameter to an int, but the test "== 0" is of no help here. > > I'm not going for type checking here because I want Signal to support > int and float samples (and numpy.int16, &c.). Ok, but the fact that amount == 0 passes, doesn't ensure you didn't a programming error, this add just some relative robustness (protect you from passing an empty list). And a reader would probably not see your intention here (he already expect a scalar due to the name of the variable). This is exactly the problem ABC is intended to solve. Without ABC, to explicitly ensure amount is a scalar, just doing a int(amount) or int(abs(amount)) if you want to deal with complex numbers too, at the begining of the function is a common idiom. -- _ Maric Michaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 3:53 am, "Russ P." <[EMAIL PROTECTED]> wrote: > Fair enough. I have no dog in this particular fight. I just think it > wouldn't hurt to add an "isempty()" or "isnonempty()" method to the > list type, and let people use it if they wish, or continue using "if > x" if that's what they prefer. Go right on ahead. You could implement it like this: class superenhancedlist(list): def isempty(self): return not self >>> a = superenhancedlist() >>> a.isempty() True >>> a.append(1) >>> a.isempty() False Amazingly useful! Go ahead and use that in all your code. Anyone else who comes along and looks at it or tries to maintain it will really love you for it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 5:09 am, Maric Michaud <[EMAIL PROTECTED]> wrote: > Le Tuesday 29 July 2008 23:48:31 [EMAIL PROTECTED], vous avez écrit : > > def print_members(iterable): > > if not iterable: > > print '' > > return > > print '' > > for item in iterable: > > print '%s' % item > > print '' > > But iterables can have no notion of emptiness too : > > >>>[25]: print_members((e for e in range(0))) > > > Ack! Maybe I meant "container" rather than "iterable". Or maybe I'd be wrong on that count, too. Other people have come up with better examples, so I won't try to fix my hasty code (although I'll keep that in mind if I have to write a custom XML writer). > > class Signal: > > [...] > > def dc_offset(self, amount): > > if amount == 0: > > return > > self.samples = [sample + amount for sample in self.samples] > > This function is also wrong assuming that because amount compare to zero, it > can be added to sample. Not quite. I'm assuming that if amount equals 0, then amount is some scalar. In fact, only if that comparison fails will I get my exception: since [] != 0, it will then try to add sample + [], which will raise TypeError. > If you want to make type checking just check the type or convert your > parameter to an int, but the test "== 0" is of no help here. I'm not going for type checking here because I want Signal to support int and float samples (and numpy.int16, &c.). > The only valuable point I see for this idiom is to make more explicit I am > testing a numerical value. That's one of the reasons I wrote it that way. Signal has other methods that take lists (like mix and envelope), which I could get confused with the ones that take scalars (offset and change volume). Cheers, Geoff G-T -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Le Tuesday 29 July 2008 23:48:31 [EMAIL PROTECTED], vous avez écrit : > Here's a function, print_members. It's just something that takes some > iterable and prints its members in XML. It's special-cased so that an > empty iterable gets an empty tag. (This is a bit of a trivial > example, I admit; the point is that the empty iterable is a special > case.) > > def print_members(iterable): > if not iterable: > print '' > return > print '' > for item in iterable: > print '%s' % item > print '' > > ... > So print_members can work on iterables that have no len(), and handle > the special case of an empty iterable, as long as __nonzero__ is > implemented. > But iterables can have no notion of emptiness too : >>>[25]: print_members((e for e in range(0))) Your function is just wrong assuming that, it should be written : >>>[31]: def print_members(iterable): print '' print '%s' % item print empty and '/>' or '' : : >>>[40]: print_members((e for e in range(0))) >>>[41]: print_members((e for e in range(1))) 0 > Counterexample: > > While "if x" works well in some circumstances, I don't like using it > for purely numeric types. For instance, I have a mutable Signal class > for doing some basic DSP. Among other things, I can apply a DC offset > to the signal (it just adds the offset to all the samples). I have a > special case for an offset of 0 so I don't have to loop through all > the samples (I also have a two-pass remove_offset method that > subtracts the average; if it's already properly centred, I can skip a > step). > > class Signal: > [...] > def dc_offset(self, amount): > if amount == 0: > return > self.samples = [sample + amount for sample in self.samples] This function is also wrong assuming that because amount compare to zero, it can be added to sample. If you want to make type checking just check the type or convert your parameter to an int, but the test "== 0" is of no help here. The only valuable point I see for this idiom is to make more explicit I am testing a numerical value. But your example is a good objection to this, with well chosen name, ie. amount, it's quite clear "if not amount :" is testing the zero value of a numerical value. -- _ Maric Michaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: Oh, Lordy. I understand perfectly well how boolean tests, __len__, and __nonzero__ work in Python. It's very basic stuff. You can quit patronizing me (and Carl too, I'm sure). The point that you seem to be missing, or refuse to acknowledge for some reason, is that "if x" can be mistakenly applied to any object when the programmer thinks that x is a list -- and the programmer will receive no feedback on the error. You know... or maybe you don't, since you did just say what you just said... that is such a ridiculous point it only barely qualifies as deserving comment. Rather than be really rude, I'll just say: test it's type() if the function is that specific, or your code that brittle. Python is not there to catch your logic mistakes, that's up to you. I have made errors like that, and I could have saved some time had I used an "empty" method that only applies to a list or other sequence. Is that an important issue? I don't know. I'm not claiming it is. But you cannot just sweep it away as nothing. I don't sweep it away as nothing -- I sweep it away as stupid. The programmer is responsible for his (or her) program. An analogy would be a driver and a car -- if the driver cannot handle the power and speed of a fancy car (python :), then the driver should get a different car better matched to his abilities. It's not up to the car to say "oh, the speed limit is 50 here, I better apply the brakes for the driver." ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: Oh, Lordy. I understand perfectly well how boolean tests, __len__, and __nonzero__ work in Python. It's very basic stuff. You can quit patronizing me (and Carl too, I'm sure). You suggested a syntax for testing non-emptiness (`x is not empty`) which indicated a profound misunderstanding of what the `is` operator does. You then acknowledged that there might be a problem because of the implication if the `is` operator and weren't sure whether it would work or not: | But I guess that could only work if there were only one empty list | that represents all empty lists (as there is only one actual "None"). | I don't know if that makes sense or not. This ends with you still sounding confused about what the operator does, because that can't make sense if you take into account the meaning of the `is` operator (surely not all empty lists are the same object) and polymorphism (not all empty containers are empty lists). Hey, everybody goofs. But pointing figures here doesn't help, since it's not unreasonable to assume that someone who says something clearly misunderstanding a feature of the language, and followups to responses _continuing to be confused about it_, is, in fact, confused. The only reason anyone thought you were confused was by your bizarre suggestion about the `empty` syntax and then your confused responses afterwards. Maybe chalk it up to experience and move on? The point that you seem to be missing, or refuse to acknowledge for some reason, is that "if x" can be mistakenly applied to any object when the programmer thinks that x is a list -- and the programmer will receive no feedback on the error. I have made errors like that, and I could have saved some time had I used an "empty" method that only applies to a list or other sequence. Well, that's what you get when you use a dynamic language. There are times when `x + y` doesn't mean numeric addition, or in fact anything like it. Or `x % y` where it _really_ doesn't mean anything like the modulus operator. In dynamic languages, the effect of operations depend on their types. There's really no way around that, and Boolean testing if an object as in `if x: ...` is no different. It means different things depending on what `x` is. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The actor is not quite a human being -- but then, who is? -- George Sanders -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: I mean in general. I wouldn't spell it like that. I would prefer if empty(x), with an __empty__ method. (And support __nonzero__ aka __bool__ dropped completely.) So your argument is purely about style, then. You just wish it were written differently. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The actor is not quite a human being -- but then, who is? -- George Sanders -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: On Jul 29, 11:36 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: Russ P. wrote: Come to think of it, shouldn't the list type have an "isempty" method? Or does it? Yes. It's written: if not aList: ... As you know, that is not quite exactly the same thing. An "isempty" method would fail if aList were an integer, and such failure might be desirable if someone mistakenly had aList pointing to an integer. If you're that concerned about what the type is, then you can do explicit typechecks. Those are discouraged precisely because of Python's dynamism. But knock yourself out. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The actor is not quite a human being -- but then, who is? -- George Sanders -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 12:49 am, Heiko Wundram <[EMAIL PROTECTED]> wrote: > Am Mittwoch, 30. Juli 2008 09:18:48 schrieb Russ P.: > > > Oh, Lordy. I understand perfectly well how boolean tests, __len__, and > > __nonzero__ work in Python. It's very basic stuff. You can quit > > patronizing me (and Carl too, I'm sure). > > I'll stop repeating what the current state is (which might sound like I'm > patronizing, but that's not the real intent actually, I'm just trying to get > the discussion straight with what is fact, namely that there already exists > an explicit way which doesn't seem to be recognized by some people here) if > you agree to my point that we're not talking about a problem with Python, but > about a personal stylistic issue with the language design. That's just what I > said in my last mail: I can concede that you, personally, have an issue with > the current state, but for me and seemingly also for a majority of people who > have posted in this thread, that's a non-issue. > > > The point that you seem to be missing, or refuse to acknowledge for > > some reason, is that "if x" can be mistakenly applied to any object > > when the programmer thinks that x is a list -- and the programmer will > > receive no feedback on the error. > > > I have made errors like that, and I could have saved some time had I > > used an "empty" method that only applies to a list or other sequence. > > For me, I've never had this kind of problem, simply because if I test for the > truth value of something, I'm going to do something with it later on, and as > soon as I'm doing something with it, I'll see whether the object supports the > interface I want it to support (and get an error there if the object doesn't > support the basic notions of a sequence type, for example, i.e. __iter__()). > Testing for truth is IMHO not doing something with an object, and as such I'm > more than happy that it's "foolproof". This is one thing that I personally > find attractive about Python's way of duck-typing. > > But, if you personally have been bitten by this, give an example, and I'm sure > that we can start discussing from there. I've already given an example why > the explicit test for length is less polymorphic than the explicit test for > truth of a container elsewhere as a proof for the point I'm trying to make. > > -- > Heiko Wundram Fair enough. I have no dog in this particular fight. I just think it wouldn't hurt to add an "isempty()" or "isnonempty()" method to the list type, and let people use it if they wish, or continue using "if x" if that's what they prefer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Am Mittwoch, 30. Juli 2008 09:18:48 schrieb Russ P.: > Oh, Lordy. I understand perfectly well how boolean tests, __len__, and > __nonzero__ work in Python. It's very basic stuff. You can quit > patronizing me (and Carl too, I'm sure). I'll stop repeating what the current state is (which might sound like I'm patronizing, but that's not the real intent actually, I'm just trying to get the discussion straight with what is fact, namely that there already exists an explicit way which doesn't seem to be recognized by some people here) if you agree to my point that we're not talking about a problem with Python, but about a personal stylistic issue with the language design. That's just what I said in my last mail: I can concede that you, personally, have an issue with the current state, but for me and seemingly also for a majority of people who have posted in this thread, that's a non-issue. > The point that you seem to be missing, or refuse to acknowledge for > some reason, is that "if x" can be mistakenly applied to any object > when the programmer thinks that x is a list -- and the programmer will > receive no feedback on the error. > > I have made errors like that, and I could have saved some time had I > used an "empty" method that only applies to a list or other sequence. For me, I've never had this kind of problem, simply because if I test for the truth value of something, I'm going to do something with it later on, and as soon as I'm doing something with it, I'll see whether the object supports the interface I want it to support (and get an error there if the object doesn't support the basic notions of a sequence type, for example, i.e. __iter__()). Testing for truth is IMHO not doing something with an object, and as such I'm more than happy that it's "foolproof". This is one thing that I personally find attractive about Python's way of duck-typing. But, if you personally have been bitten by this, give an example, and I'm sure that we can start discussing from there. I've already given an example why the explicit test for length is less polymorphic than the explicit test for truth of a container elsewhere as a proof for the point I'm trying to make. -- Heiko Wundram -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 12:03 am, Heiko Wundram <[EMAIL PROTECTED]> wrote: > Am Mittwoch, 30. Juli 2008 08:30:48 schrieb Russ P.: > > > On Jul 29, 11:09 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > > > I'm getting this sneaking suspicion that you guys are all putting us on. > > > As I said in an earlier post, I realize that this would only work if > > there were only one copy of "empty" (as there is only one copy of > > "None"). I don't know off hand if that is feasible or not. > > > You reply reeks of the kind of pedantic snobbishness that makes me > > sick. > > I can understand (and pretty much sympathise) that you get this kind of reply, > simply because the point you and Carl Banks (formulated somewhat differently) > put up has been answered again and again (in this thread), and I can only > repeat it once more: > > __nonzero__(), i.e. the "cast" to boolean, is THE WAY to test whether a > container is empty or not. Like this design decision, or don't like it, but > the discussion is not going to go anywhere unless you concede that there is a > (very explicit!) way to test for non-emptiness of a container already, and > you're currently simply discussing about adding/using syntactic sugar > (different means of expressing the test) to suit your own personal taste > better. Anyway, check the documentation for __nonzero__(): if the object > doesn't implement that, but implements __len__(), the interpreter "replaces" > the __nonzero__() test by __len__()>0, so I guess someone in the design > department must've seen it logical for the truth value of a container to > express the test "len(x)>0" at some point in time to make this interpretation > for the truth value of a container. > > There cannot be an argument about missing/misplaced functionality (that's what > you make it sound like), if the functionality for doing what you want to do > is there and you simply don't like the syntax, which I can somewhat relate to > because style is a personal thing, even though I don't see either points made > by you or Carl Banks, because implicit casting to bool is so common in pretty > much every programming language to test for "truth" of an object, and IMHO > it's completely logical to extend that idea to containers to mean > empty/non-empty. > > Eric Max Francis tried to explain why your syntactic "enhancement" would come > at a much greater price than its worth, and he's absolutely right in that, as > it's an abuse of the "is" operator, but again, that's a somewhat different > point. It changes nothing about the fact that all this discussion centers > around something that is a non-point, but simply a matter of personal taste. > > -- > Heiko Wundram Oh, Lordy. I understand perfectly well how boolean tests, __len__, and __nonzero__ work in Python. It's very basic stuff. You can quit patronizing me (and Carl too, I'm sure). The point that you seem to be missing, or refuse to acknowledge for some reason, is that "if x" can be mistakenly applied to any object when the programmer thinks that x is a list -- and the programmer will receive no feedback on the error. I have made errors like that, and I could have saved some time had I used an "empty" method that only applies to a list or other sequence. Is that an important issue? I don't know. I'm not claiming it is. But you cannot just sweep it away as nothing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Am Mittwoch, 30. Juli 2008 08:30:48 schrieb Russ P.: > On Jul 29, 11:09 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > > I'm getting this sneaking suspicion that you guys are all putting us on. > > As I said in an earlier post, I realize that this would only work if > there were only one copy of "empty" (as there is only one copy of > "None"). I don't know off hand if that is feasible or not. > > You reply reeks of the kind of pedantic snobbishness that makes me > sick. I can understand (and pretty much sympathise) that you get this kind of reply, simply because the point you and Carl Banks (formulated somewhat differently) put up has been answered again and again (in this thread), and I can only repeat it once more: __nonzero__(), i.e. the "cast" to boolean, is THE WAY to test whether a container is empty or not. Like this design decision, or don't like it, but the discussion is not going to go anywhere unless you concede that there is a (very explicit!) way to test for non-emptiness of a container already, and you're currently simply discussing about adding/using syntactic sugar (different means of expressing the test) to suit your own personal taste better. Anyway, check the documentation for __nonzero__(): if the object doesn't implement that, but implements __len__(), the interpreter "replaces" the __nonzero__() test by __len__()>0, so I guess someone in the design department must've seen it logical for the truth value of a container to express the test "len(x)>0" at some point in time to make this interpretation for the truth value of a container. There cannot be an argument about missing/misplaced functionality (that's what you make it sound like), if the functionality for doing what you want to do is there and you simply don't like the syntax, which I can somewhat relate to because style is a personal thing, even though I don't see either points made by you or Carl Banks, because implicit casting to bool is so common in pretty much every programming language to test for "truth" of an object, and IMHO it's completely logical to extend that idea to containers to mean empty/non-empty. Eric Max Francis tried to explain why your syntactic "enhancement" would come at a much greater price than its worth, and he's absolutely right in that, as it's an abuse of the "is" operator, but again, that's a somewhat different point. It changes nothing about the fact that all this discussion centers around something that is a non-point, but simply a matter of personal taste. -- Heiko Wundram -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 1:58 am, "Russ P." <[EMAIL PROTECTED]> wrote: > On Jul 29, 10:33 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > > > On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: > > > Having said that, it would sure be nice to be able to write > > > > if myList is not empty: > > > > instead of > > > > if len(myList) != 0: > > > I can agree with this. > > But I guess that could only work if there were only one empty list > that represents all empty lists (as there is only one actual "None"). > I don't know if that makes sense or not. I mean in general. I wouldn't spell it like that. I would prefer if empty(x), with an __empty__ method. (And support __nonzero__ aka __bool__ dropped completely.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 2:06 am, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Perhaps in the particular use case you're thinking of (numeric types vs. > container types), there aren't any good examples. But who cares? You don't have to. I am trying to set the record straight on just how much polymophism "if x" supports relative to explicit tests, which is to say, not much. BTW, I haven't changed my criteria since I asked for the challenge. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 11:36 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > Come to think of it, shouldn't the list type have an "isempty" method? > > Or does it? > > Yes. It's written: > > if not aList: > ... As you know, that is not quite exactly the same thing. An "isempty" method would fail if aList were an integer, and such failure might be desirable if someone mistakenly had aList pointing to an integer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 11:36 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > On Jul 29, 11:09 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > > >> I'm getting this sneaking suspicion that you guys are all putting us on. > > > As I said in an earlier post, I realize that this would only work if > > there were only one copy of "empty" (as there is only one copy of > > "None"). I don't know off hand if that is feasible or not. > > It's only feasible if you change what `is` means for this one bizarre > use case, which isn't a good idea. > > > You reply reeks of the kind of pedantic snobbishness that makes me > > sick. > > Well, if understanding what the `is` operator means is pedantic > snobbishness, then hey, go right ahead. > > -- > Erik Max Francis && [EMAIL PROTECTED] &&http://www.alcyone.com/max/ > San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis >The doors of Heaven and Hell are adjacent and identical. > -- Nikos Kazantzakis I fully understand what the "is" operator is, and I never had any problem with it at all, thank you. But then again, I suppose that depends on what the meaning of "is" is ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: Come to think of it, shouldn't the list type have an "isempty" method? Or does it? Yes. It's written: if not aList: ... -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The doors of Heaven and Hell are adjacent and identical. -- Nikos Kazantzakis -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: On Jul 29, 11:09 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: I'm getting this sneaking suspicion that you guys are all putting us on. As I said in an earlier post, I realize that this would only work if there were only one copy of "empty" (as there is only one copy of "None"). I don't know off hand if that is feasible or not. It's only feasible if you change what `is` means for this one bizarre use case, which isn't a good idea. You reply reeks of the kind of pedantic snobbishness that makes me sick. Well, if understanding what the `is` operator means is pedantic snobbishness, then hey, go right ahead. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The doors of Heaven and Hell are adjacent and identical. -- Nikos Kazantzakis -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 11:16 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Russ P. wrote: > > On Jul 29, 10:33 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > >> On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: > > >>> Having said that, it would sure be nice to be able to write > >>> if myList is not empty: > >>> instead of > >>> if len(myList) != 0: > >> I can agree with this. > > > But I guess that could only work if there were only one empty list > > that represents all empty lists (as there is only one actual "None"). > > I don't know if that makes sense or not. > > It really doesn't, since it presumably wouldn't apply to just list > types. There are plenty of other sequence types: such as tuples, > strings, or even arbitrary custom types. Emptiness is a test for the > value of an object, not a test for whether it is identical to another > object, so this is a very misleading of the `is` operator, bordering on > abuse. > > This syntax would make far less sense than the existing Boolean test. > > -- > Erik Max Francis && [EMAIL PROTECTED] &&http://www.alcyone.com/max/ > San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis >The doors of Heaven and Hell are adjacent and identical. > -- Nikos Kazantzakis Now that's more reasonable. Note that I said, "it would be nice to be able to write," not "this is how it should be done." Come to think of it, shouldn't the list type have an "isempty" method? Or does it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 11:09 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > I'm getting this sneaking suspicion that you guys are all putting us on. As I said in an earlier post, I realize that this would only work if there were only one copy of "empty" (as there is only one copy of "None"). I don't know off hand if that is feasible or not. You reply reeks of the kind of pedantic snobbishness that makes me sick. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: On Jul 29, 10:33 pm, Carl Banks <[EMAIL PROTECTED]> wrote: On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: Having said that, it would sure be nice to be able to write if myList is not empty: instead of if len(myList) != 0: I can agree with this. But I guess that could only work if there were only one empty list that represents all empty lists (as there is only one actual "None"). I don't know if that makes sense or not. It really doesn't, since it presumably wouldn't apply to just list types. There are plenty of other sequence types: such as tuples, strings, or even arbitrary custom types. Emptiness is a test for the value of an object, not a test for whether it is identical to another object, so this is a very misleading of the `is` operator, bordering on abuse. This syntax would make far less sense than the existing Boolean test. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The doors of Heaven and Hell are adjacent and identical. -- Nikos Kazantzakis -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: All this discussion about "if x" has me wondering. I use it all the time because a fully explicit test just seems redundant. But maybe it does have some value in terms of readability and type checking. After all, it is possible to forget whether something is a number or a list. IMO, the only time I think "if x" is really dangerous is if you are using "if x" instead of "if x is None" to distinguish between None and a type that can have false values. Well, that would be an exceptionally bad way to test for None-ness, since None is false. The test would never succeed. Having said that, it would sure be nice to be able to write if myList is not empty: instead of if len(myList) != 0: I can agree with this. I'm getting this sneaking suspicion that you guys are all putting us on. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The doors of Heaven and Hell are adjacent and identical. -- Nikos Kazantzakis -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Russ P. wrote: All this discussion about "if x" has me wondering. I use it all the time because a fully explicit test just seems redundant. But maybe it does have some value in terms of readability and type checking. After all, it is possible to forget whether something is a number or a list. Having said that, it would sure be nice to be able to write if myList is not empty: I sure hope that's a joke. `x is not y` means something quite different. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis The doors of Heaven and Hell are adjacent and identical. -- Nikos Kazantzakis -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: Bull. This is a request, that, if satisfied, would prove that "if x" is more polymorphic than a simple explicit test. I posed the question precisely to see if anyone could come up with a use case that shows this benefit of "if x". Except you're the only one who's not convinced of it, and it's your test, and your rules. So who cares? "if x" _is_ a completely simple test. Simpler, in fact, than the ones you were advocating. It's not explicit. It's not explicit enough for you, yes, that much is obvious. Contests that rely on mind-reading aren't too much fun for anyone involved. I've explained why I doubt that it helps polymorphism that much: you almost never see code for which an integer and list both work, so having the ability to spell a test the same way for both types isn't useful. If you claim that "if x" does help polymorphism, please tell me what's wrong with the above analysis. It helps polymorphism for types other that (say) numerics and sequences. There are plenty of container objects for which an "is this non-empty?" test is far simpler a "how many objects are in this container?" test, and several examples have already been given -- as in, O(1) vs. O(n) complexity or worse. You've seem to have even acknowledged this, but are still insisting on continuing the challenge. You're drawing an artificial line in the sand to compare length computation to a more specialized non-emptiness test. (And, as I've pointed out, what happens if you're dealing with a sequence type that _doesn't_ have a length? Then certainly `len(x) != 0` is nonsensical.) Perhaps in the particular use case you're thinking of (numeric types vs. container types), there aren't any good examples. But who cares? Polymorphism applies in more than just this one special case. You're setting up a challenge that isn't very interesting, and which is rigged so that no one can win because you're the one who. So, what's the point? -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis Can I be your friend / 'Till the end -- India Arie -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 10:33 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: > > Having said that, it would sure be nice to be able to write > > > if myList is not empty: > > > instead of > > > if len(myList) != 0: > > I can agree with this. But I guess that could only work if there were only one empty list that represents all empty lists (as there is only one actual "None"). I don't know if that makes sense or not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 1:15 am, "Russ P." <[EMAIL PROTECTED]> wrote: > All this discussion about "if x" has me wondering. I use it all the > time because a fully explicit test just seems redundant. But maybe it > does have some value in terms of readability and type checking. After > all, it is possible to forget whether something is a number or a list. IMO, the only time I think "if x" is really dangerous is if you are using "if x" instead of "if x is None" to distinguish between None and a type that can have false values. Well, also it can backfire to use "if x" to check whether an iterable is empty since you can get a false positive if it's an iterator. Other than that it's maybe slighly less type safe to use explicit test. > Having said that, it would sure be nice to be able to write > > if myList is not empty: > > instead of > > if len(myList) != 0: I can agree with this. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 6:42 pm, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > Much like in Steven D'Aprano's example, still the only actual code > > snippet I've seen, it seems that this can easily be done with a simple > > explicit test by having all no-advance filters return None and testing > > with "if x is not None". So it doesn't pass my criterion of being not > > replaceable with simple explicit test. > > > Maybe that's not workable for some reason. Perhaps if you'd post a > > code example that shows this, rather than just talking about it, you > > might be more persuasive. > > > Carl Banks > > -- > >http://mail.python.org/mailman/listinfo/python-list > > The no-advance filters have to return the object because I don't just > forget about it; I evaluate whether I pass it to the next filter or drop > it in a completely different queue for use in the next stage of the > operation. True means 'I'm ready to move on to the next stage,' False > means 'Do the filter thing some more.' I think I see what you're saying, and yeah I guess that could really take advantage of polymorphism between very different types. > Furthermore, the argument that I should just change my API to make a > 'simple test' work is not very convincing. I wasn't suggesting you change it: I was trying to ascertain whether it would have suffered much if you had written it with explicit tests in the first place, or if Python didn't even have magical booleans. > The natural, obvious way for > a filter to work is to pass through the data it operates on; why on > Earth would it return None? I want to DO something with the data. In > this case, make a decision about where to pass the data next. If you don't mind me asking: what do you do actually DO with a zero or empty list? > In Java, > to accomplish this I would have to do lots of introspection and value > checking (adding more any time I came up with a new kind of input), or > make a new kind of interface that gives me a method so I can do a > 'simple test' (including wrappers for ints and arrays and anything else > I decide to pass in down the road). But Python supports duck typing and > gives me a handy __nonzero__ method; I can rebind __nonzero__ in my > filters for my own classes, and ints and lists are handled how I want > them to be by default. So why jump through hoops instead of just using > 'if x'? Ah, so it's just happens to work. Still, just happening to work works. (shrug) > I don't have any postable code (it's in a half way state and I haven't > touched it for a while), but I'll see if I can't find the time to bang > something up to give you the gist. I wouldn't bother at this point. I was looking to see if someone could come up with something to disprove my belief on the polymorphic uselessness of "if x" relative to explicit tests, and if (as I anticipated) they did not, I could claim that "if x" is really just a glorified keystroke saver. But I now realize that the failure of this bunch doesn't prove anything. I don't think most people even realize why answering the question I asked would demonstrate the usefulness of "if x". Your example isn't exactly the smoking gun I was looking for, but I guess we'll have to admit that at least one usage will suffer for not having it. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 9:52 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > On Jul 29, 11:17 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > > > > > Carl Banks wrote: > > >> As I wrote in the second reply email I sent, check out my integer set > > >> recipe on ASPN (and to save you the search: > > >> http://code.activestate.com/recipes/466286/). > > > > Couple points: > > > > 1. Any container type that returns a length that isn't exactly the > > > number of elements in it is broken. > > > 2. The need for __nonzero__ in this case depends on a limitation in > > > the language. > > > 3. On the other hand, I will concede that sometimes calculating len is > > > a lot more expensive than determining emptiness, and at a basic level > > > it's important to avoid these costs. You have found a practical use > > > case for __nonzero__. > > > I thought of another one: testing whether an iterator is 'empty' (will > > raise StopIteration on the next next() (3.0) call) or not. As virtual > > collections, iterators generally have neither __len__ or __bool__. But > > __bool__ (but only __bool__) can be added to any iterator by wrapping it > > with something like the following 3.0 code (not tested): > > > class look_ahead_it(): > >def __init__(self, iterable): > > self.it = iter(iterable) > > self.fill_next() > > >def __iter__(self): > > return self > >def __next__(self): > > tem = self.next > > if tem is self.empty: > >raise StopIteration > > else: > >self.fill_next() > >return tem > > >empty = object() > >def fill_next(self) > > try: > >self.next = next(self.it) > > except StopIteration: > >self.next = self.empty > > >def __bool__(self): > > return self.next is not self.empty > > Iterators are funny: if there's any reason you should not use "if x" > it's because of them. Built-in iterators are always true, so if > you're writing a function that accepts an iterable you should never > use the "if x" to test whether it's empty, because it fails for a > whole class of iterables. > > However, given that that wart exists, your example does work for "if > x" and not with "if len(x)!=0". > > Then again, it really only works to accommodate faulty code, because > no code that expects an iterable should be using that test in the > first place. (Unless you wrap every iterable as soon as you get it, > but then you're not bound to use __nonzero__.) > > Carl Banks All this discussion about "if x" has me wondering. I use it all the time because a fully explicit test just seems redundant. But maybe it does have some value in terms of readability and type checking. After all, it is possible to forget whether something is a number or a list. Having said that, it would sure be nice to be able to write if myList is not empty: instead of if len(myList) != 0: -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 11:17 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > >> As I wrote in the second reply email I sent, check out my integer set > >> recipe on ASPN (and to save you the search: > >> http://code.activestate.com/recipes/466286/). > > > Couple points: > > > 1. Any container type that returns a length that isn't exactly the > > number of elements in it is broken. > > 2. The need for __nonzero__ in this case depends on a limitation in > > the language. > > 3. On the other hand, I will concede that sometimes calculating len is > > a lot more expensive than determining emptiness, and at a basic level > > it's important to avoid these costs. You have found a practical use > > case for __nonzero__. > > I thought of another one: testing whether an iterator is 'empty' (will > raise StopIteration on the next next() (3.0) call) or not. As virtual > collections, iterators generally have neither __len__ or __bool__. But > __bool__ (but only __bool__) can be added to any iterator by wrapping it > with something like the following 3.0 code (not tested): > > class look_ahead_it(): >def __init__(self, iterable): > self.it = iter(iterable) > self.fill_next() > >def __iter__(self): > return self >def __next__(self): > tem = self.next > if tem is self.empty: >raise StopIteration > else: >self.fill_next() >return tem > >empty = object() >def fill_next(self) > try: >self.next = next(self.it) > except StopIteration: >self.next = self.empty > >def __bool__(self): > return self.next is not self.empty Iterators are funny: if there's any reason you should not use "if x" it's because of them. Built-in iterators are always true, so if you're writing a function that accepts an iterable you should never use the "if x" to test whether it's empty, because it fails for a whole class of iterables. However, given that that wart exists, your example does work for "if x" and not with "if len(x)!=0". Then again, it really only works to accommodate faulty code, because no code that expects an iterable should be using that test in the first place. (Unless you wrap every iterable as soon as you get it, but then you're not bound to use __nonzero__.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 30, 12:22 am, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > That's not what I was asking for. I was asking for a use case for "if > > x" that can't be replaced by a simple explicit test. Your example > > didn't satisfy that. > > It's a completely artificial request. Bull. This is a request, that, if satisfied, would prove that "if x" is more polymorphic than a simple explicit test. I posed the question precisely to see if anyone could come up with a use case that shows this benefit of "if x". > "if x" _is_ a completely simple > test. Simpler, in fact, than the ones you were advocating. It's not explicit. Here's what we know for sure. 1. "if x" uses fewer keystrokes than an explicit test 2. "if x" creates fewer nodes in the parse tree than an explicit test 3. Couple minor things we somehow managed to uncover in this thread Is that it? Is that all the benefits of "if x"? This is what I want to establish. A bunch of people in this thread are crowing that it helps polymorphism, but I have only seen minor examples of it. I've explained why I doubt that it helps polymorphism that much: you almost never see code for which an integer and list both work, so having the ability to spell a test the same way for both types isn't useful. If you claim that "if x" does help polymorphism, please tell me what's wrong with the above analysis. Or just give me the use case I asked for. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Attack a sacred Python Cow
On Jul 29, 2:27 am, Iain King <[EMAIL PROTECTED]> wrote: > On Jul 29, 5:33 am, "Russ P." <[EMAIL PROTECTED]> wrote: > > > > > On Jul 28, 8:44 pm, alex23 <[EMAIL PROTECTED]> wrote: > > > > On Jul 29, 4:46 am, "Russ P." <[EMAIL PROTECTED]> wrote: > > > > > As I said, I could write a pre-processor myself to > > > > implement it in less than a day. > > > > So WHY DON'T YOU WRITE IT ALREADY? > > > I'm working on something else right now if you don't mind, but I'll > > get to it in good time. > > > Conceptually, the matter is simple. All I need to do is to grab the > > first formal argument of each def, then search for occurrences of any > > word in the body of the def that starts with a dot, and insert that > > first argument in front of it. > > > I expect the "hard" part will be breaking up the body of the def into > > "words." I could just split each line on white space, except for > > situations like > > > x+=.zzz > > > So I need to account for the fact that operators do not need to be > > surrounded by spaces. That's the hardest part I can think of off the > > top of my head. > > > Maybe I'll encounter an insurmountable problem and realize that the > > idea can't work in general. If so, then so be it. Certainly, no one on > > this thread has anticipated such a problem. Had someone pointed out an > > actual technical problem with the idea, I would have gladly thanked > > them. But I got a load of irrelevant crap instead, not to mention > > being addressed as "boy." > > > > If you're meeting so much resistance to your idea, why not scratch > > > your own damn itch and just do it? > > > > Or doesn't that afford you as many chances to insult others while > > > feeling smugly superior? > > > This coming from a guy who insulted my reading comprehension ability > > -- when he was the one who was wrong! > > Are you actually this stupid? I mean, you were entertaining while you > were mouthing of and insulting your betters, but now you're gonna > complain the second anyone insults you (and I mean, 'boy' - what an > insult!). Never mind that you're never gonna get off your ass to > write a PEP, which would be rejected on language design grounds anyway > (as demonstrated by alex23's link - the one you aren't > comprehending). The most irritating thing is that I like the idea of > being able to use '.x = 10' type notation (and have been for a long > time), but the person arguing for it is an insufferable buffoon who's > too dense to understand a cogent argument, never mind make one. So > great, thanks, the chances of this (or a VB 'with'-like 'using' > keyword) ever making it into the language get smaller every time you > fire up your keyboard. Nice work. > > Iain > > p.s. am looking forward to your post whining about the invalid reasons > your PEP got rejected, in the slim hope you actually write one. +1 POTW Thanks for the gentle prod! I'm on it -- well, soon anyway. I have to consciously avoid thinking about this post whenever I consume a beverage! -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 7:30 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Tue, 29 Jul 2008 10:30:43 -0700, Carl Banks wrote: > > On Jul 29, 5:15 am, Heiko Wundram <[EMAIL PROTECTED]> wrote: > >> I can't dig up a simple example from code I wrote quickly, but because > >> of the fact that explicit comparisons always hamper polymorphism > > > I'm not going to take your word for it. Do you have code that > > demonstrates how "if x" improves polymorphism relative to simple > > explicit tests? > > On the rapidly decreasing chance that you're not trolling (looking more > and more unlikely every time you post): > > # The recommended way: > if x: > do_something > > # Carl's so-called "simple explicit tests" applied to polymorphic code: No, the following isn't my way. > try: > # could be a sequence or mapping? > # WARNING: must do this test *before* the number test, otherwise > # "if [] != 0" will return True, leading to the wrong branch being > # taken. > if len(x) != 0: > do_something > except AttributeError: > # not a sequence or mapping, maybe it's a number of some sort > try: > int(x) > except TypeError: > # not convertable to numbers > # FIXME: not really sure what to do here for arbitrary types > # so fall back on converting to a boolean, and hope that works > if bool(x): > do_something > else: > if x != 0: > do_something I say that you will never, ever have to do this because there isn't a do_something that's actually useful for all these types. Ok, tell me, oh indignant one, what is do_something? What could possibly be the contents of do_something such that it actually does something useful? If you can tell me what do_something is you will have answered my question. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: That's not what I was asking for. I was asking for a use case for "if x" that can't be replaced by a simple explicit test. Your example didn't satisfy that. It's a completely artificial request. "if x" _is_ a completely simple test. Simpler, in fact, than the ones you were advocating. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis An ounce of hypocrisy is worth a pound of ambition. -- Michael Korda -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Jul 29, 10:23 pm, Erik Max Francis <[EMAIL PROTECTED]> wrote: > Carl Banks wrote: > > Bzzt. "if len(x)!=0" is a simple explicit that would work for this > > class and all built-in containers. (Or should--Steven D'Aprano's > > objections notwithstanding, any reasonable container type should > > support this invariant. From a language design standpoint, an "empty" > > builtin could have been created to simplify this even more, but since > > there isn't one len(x)!=0 will have to do.) > > That you choose not to test for non-emptiness doesn't change the fact > that it's already a builtin part of the language that is supported by > all fundamental types and is overridable by anyone writing a custom > type. Use it or don't use it, but it's an example of precisely what you > were asking for that is both practical and already in widespread use. That's not what I was asking for. I was asking for a use case for "if x" that can't be replaced by a simple explicit test. Your example didn't satisfy that. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: As I wrote in the second reply email I sent, check out my integer set recipe on ASPN (and to save you the search: http://code.activestate.com/recipes/466286/). Couple points: 1. Any container type that returns a length that isn't exactly the number of elements in it is broken. 2. The need for __nonzero__ in this case depends on a limitation in the language. 3. On the other hand, I will concede that sometimes calculating len is a lot more expensive than determining emptiness, and at a basic level it's important to avoid these costs. You have found a practical use case for __nonzero__. I thought of another one: testing whether an iterator is 'empty' (will raise StopIteration on the next next() (3.0) call) or not. As virtual collections, iterators generally have neither __len__ or __bool__. But __bool__ (but only __bool__) can be added to any iterator by wrapping it with something like the following 3.0 code (not tested): class look_ahead_it(): def __init__(self, iterable): self.it = iter(iterable) self.fill_next() def __iter__(self): return self def __next__(self): tem = self.next if tem is self.empty: raise StopIteration else: self.fill_next() return tem empty = object() def fill_next(self) try: self.next = next(self.it) except StopIteration: self.next = self.empty def __bool__(self): return self.next is not self.empty -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: Bzzt. "if len(x)!=0" is a simple explicit that would work for this class and all built-in containers. (Or should--Steven D'Aprano's objections notwithstanding, any reasonable container type should support this invariant. From a language design standpoint, an "empty" builtin could have been created to simplify this even more, but since there isn't one len(x)!=0 will have to do.) That you choose not to test for non-emptiness doesn't change the fact that it's already a builtin part of the language that is supported by all fundamental types and is overridable by anyone writing a custom type. Use it or don't use it, but it's an example of precisely what you were asking for that is both practical and already in widespread use. Now, you guys keep whining "But what if you don't know what kind of object you're expecting?!!" It's a fair question, and my belief is that, in practice, this almost never happens. Duck typing happens between numeric types often, and between container types often, but almost never between both numeric and container types. Their usages are simply too different. What should a custom type return as its length to pass your non-emptiness test if it's a custom sequence class that is an infinite generator? It's non-empty, but doesn't have a length. You test for non-emptiness by Boolean comparison, not by testing its length. So I present another question to you: Give me an useful, non-trivial, example of some code that where x could be either a numeric or container type. That would be the first step to finding a counterexample. (The next step would be to show that it's useful to use "if x" in such a context.) Well, asked and answered, but it apparently wasn't good enough, so I doubt anyone's going to enjoy playing your game much further. You're asking for an example of something that demonstrates a use case that's _already used by all the builtin types_, so eh, have fun drawing imaginary lines in the sand. Once again, I'm invoking the contraint against simply using x in a boolean context, or passing x to a function expecting a boolean doesn't count, since in those cases x can be set to the result of the explicit test. Next answer you're just add another constraint, so I suspect the only one enjoying this word game is you. -- Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis Love is the selfishness of two persons. -- Antoine de la Salle -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Tue, 29 Jul 2008 13:53:07 -0700, Carl Banks wrote: > Bzzt. "if len(x)!=0" is a simple explicit that would work for this > class and all built-in containers. (Or should--Steven D'Aprano's > objections notwithstanding, any reasonable container type should support > this invariant. What's the length of an empty list with a sentinel at the end? What's the length of a binary tree? Does it even have a length? What's the length of a constant-sized table where each position might be in use or free? You're making assumptions about what an empty object "should" look like. I say, just ask the object if it's empty, don't try to guess how you would find out. Maybe the object carries around a flag x.isempty. Who knows? Why do you care? You're basing your code on implementation details. That should be avoided whenever possible. [...] > Once again, I'm invoking the contraint against simply using x in a > boolean context, So, to put it another way... you want us to give you an example of using x in a boolean context, but you're excluding any example where we use x in a boolean context. Right-o, I've had enough of your trolling. I'm out of here. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Tue, 29 Jul 2008 21:15:12 +0100, Matthew Woodcraft wrote: > Steven D'Aprano <[EMAIL PROTECTED]> wrote: >> "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.) > > There are many circumstances where if a parameter is None I'd rather get > an exception than have the code carry on with the 'empty container' > branch (and silently give me a meaningless result). Sure. The way I'd handle that is test for None at the start of the function, and raise an error there, rather than deal with it at some arbitrary part of the function body. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Tue, 29 Jul 2008 10:42:50 -0700, Carl Banks wrote: > On Jul 29, 11:12 am, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: ... >> My use case involves a DAG of filters that pass data (of a variety of >> types--filters just pass on data types they don't understand) between >> them. I can also drop out of the filter chain at any point, using >> critera determined by the filters. These criteria, you guessed it, are >> bound to __nonzero__ in the filter and I determine whether or not to >> continue through the graph using "if x". You can't code explicit tests >> if you don't know what the tests even are beforehand. Also, I wanted to >> support builtins (ints and lists in particular) because they can be >> meaningful inputs to filters. Finally, as I add more filters and data >> types, I don't want to go back and mess with the code that decides >> whether or not to break out of the graph. > > Much like in Steven D'Aprano's example, still the only actual code > snippet I've seen, it seems that this can easily be done with a simple > explicit test by having all no-advance filters return None and testing > with "if x is not None". Yet again you ignore the actual functional requirements of the code, and made vague claims that if we change the function to another function that behaves differently, we can replace our simple code with your more complex code, and it (probably) won't break. Even if we could redesign the functional requirements of the code, why on earth would we want to? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Tue, 29 Jul 2008 10:30:43 -0700, Carl Banks wrote: > On Jul 29, 5:15 am, Heiko Wundram <[EMAIL PROTECTED]> wrote: >> I can't dig up a simple example from code I wrote quickly, but because >> of the fact that explicit comparisons always hamper polymorphism > > I'm not going to take your word for it. Do you have code that > demonstrates how "if x" improves polymorphism relative to simple > explicit tests? On the rapidly decreasing chance that you're not trolling (looking more and more unlikely every time you post): # The recommended way: if x: do_something # Carl's so-called "simple explicit tests" applied to polymorphic code: try: # could be a sequence or mapping? # WARNING: must do this test *before* the number test, otherwise # "if [] != 0" will return True, leading to the wrong branch being # taken. if len(x) != 0: do_something except AttributeError: # not a sequence or mapping, maybe it's a number of some sort try: int(x) except TypeError: # not convertable to numbers # FIXME: not really sure what to do here for arbitrary types # so fall back on converting to a boolean, and hope that works if bool(x): do_something else: if x != 0: do_something But wait... that can be re-written as follows: if bool(x): do_something and that can be re-written without the call to bool: if x: do_something -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
Carl Banks wrote: On Jul 29, 11:12 am, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote: 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. I am looking for one that can't. 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. I am seeking the answer to one question: whether "if x" can usefully do something a simple explicit test can't. Everyone already knows that "if x" requires fewer keystrokes and parses to fewer nodes. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list My use case involves a DAG of filters that pass data (of a variety of types--filters just pass on data types they don't understand) between them. I can also drop out of the filter chain at any point, using critera determined by the filters. These criteria, you guessed it, are bound to __nonzero__ in the filter and I determine whether or not to continue through the graph using "if x". You can't code explicit tests if you don't know what the tests even are beforehand. Also, I wanted to support builtins (ints and lists in particular) because they can be meaningful inputs to filters. Finally, as I add more filters and data types, I don't want to go back and mess with the code that decides whether or not to break out of the graph. Much like in Steven D'Aprano's example, still the only actual code snippet I've seen, it seems that this can easily be done with a simple explicit test by having all no-advance filters return None and testing with "if x is not None". So it doesn't pass my criterion of being not replaceable with simple explicit test. Maybe that's not workable for some reason. Perhaps if you'd post a code example that shows this, rather than just talking about it, you might be more persuasive. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list The no-advance filters have to return the object because I don't just forget about it; I evaluate whether I pass it to the next filter or drop it in a completely different queue for use in the next stage of the operation. True means 'I'm ready to move on to the next stage,' False means 'Do the filter thing some more.' Furthermore, the argument that I should just change my API to make a 'simple test' work is not very convincing. The natural, obvious way for a filter to work is to pass through the data it operates on; why on Earth would it return None? I want to DO something with the data. In this case, make a decision about where to pass the data next. In Java, to accomplish this I would have to do lots of introspection and value checking (adding more any time I came up with a new kind of input), or make a new kind of interface that gives me a method so I can do a 'simple test' (including wrappers for ints and arrays and anything else I decide to pass in down the road). But Python supports duck typing and gives me a handy __nonzero__ method; I can rebind __nonzero__ in my filters for my own classes, and ints and lists are handled how I want them to be by default. So why jump through hoops instead of just using 'if x'? I don't have any postable code (it's in a half way state and I haven't touched it for a while), but I'll see if I can't find the time to bang something up to give you the gist. -Matt -- http://mail.python.org/mailman/listinfo/python-list
