Francisco Gracia <fgragu...@gmail.com> added the comment: Thank you both for your quick and clear explanations. However I regret that I keep considering the situation rather unsatisfactory.
I can well understand that all objects are true and even that the convention that applies to some of them, like containers, that when they are empty they be considered false, does not apply to iterators; no doubt there will be good reasons for it being so. What seems illogical to me is that a method like *re.finditer()* returns as the result of its execution something that can only be interpreted as implying that what happened is exactly the contrary of what it really was. Why does it have to return anything different from the standard *None* when the match fails, like any other operation that fails? What use is in an *iterator* that leads nowhere? I would find clarifying if at least the documentation formulated unambigously that it is unwise to submit iterators (and specifically the ones returned by methods like *finditer()* whose same names imply the opposite) to logical testing and that the only valid use they have is as arguments in *for* loops. I think that the same vagorosity in this respect transpires in other places of the documentation. For instance in paragraph 7.2.5 of *re.html* it is said: Match objects always have a boolean value of *True*, so that you can test whether e. g. *match()* resulted in a match with a simple *if* statement. As it is formulated, this clause is clearly contradictory: if something points always in the same direction, it cannot be used as the basis for any decission about which of two roads to take. Match objects can very well be always true (in fact, as all objects are in this sense, as paragraph 5.1 of *stdtypes.html* comes close to formulating it); what happens is that *re.match()* or *re.search()* do not return them when they fail, but the familiar and well behaved *None* value. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14924> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
