Tal Einat wrote: > Neil Cerutti wrote: > > On 2006-09-01, Tal Einat <[EMAIL PROTECTED]> wrote: > > > Tim Chase wrote: > > >> I'm not sure if '__iter__' is the right thing to be looking > > >> for, but it seems to work at least for lists, sets, > > >> dictionarys (via their keys), etc. I would use it because at > > >> least then you know you can iterate over it > > > > > > AFAIK and as seen throughout posts on c.l.py, the best way to > > > check if something is iterable is: > > > > > > try: > > > iter(obj) > > > except TypeError: > > > <obj is not iterable> > > > else: > > > <obj is iterable> > > > > That confounds me. Of course, I'm coming from a C++, where you > > never want to throw an exception in a common case, hence the name > > 'exception'. The Python FAQ does say that raising and catching an > > exception is an expensive operation. I see that type-checking is > > good to avoid, but type-checking must be better than "abusing" > > exceptions in this way. Is the above really a popular idiom? > > > > If so, I guess I'll get used to it. > > > Such use of exceptions is surely common enough in Python to be worth > getting to know, if only in order to understand others' code. > > If you had wanted to check if an object was callable, which is a more > basic functionality in Python, you would use Python's built-in function > callable(). Unfortunately there is no such function as iterable(). > (perhaps there should be? ...) > > Raising an exception is a relatively "expensive" operation, but not so > much that you would want to avoid it altogether... In most such cases, > such as checking whether an object is iterable, speed isn't an issue. > > IMO this is far from "abuse". The iter() function's documenation > explicitly notes "If it does not support either of those protocols, > TypeError is raised." This can be viewed as one possible output of the > function, in addition to the possibility of returning an iterator. In > such a function, raising exceptions instead of returning None or other > special values (often called "return codes") is much more modular, and > IMO much more readable. > > - Tal
I agree. Code readability is much more important than code performance (Well, in the Python realm.). A Python coder shouldn't care about performance until he/she does a profiling and finds out a bottleneck. Besides, I like my solution a little better :). When performing the extend in the try, the extend will raise TypeError anyway. No need to call iter(). It's what my Python in a nutshell book calls "It's easier to ask forgiveness than permission" idiom, as opposed to the "Look before you leap" idiom. -- http://mail.python.org/mailman/listinfo/python-list
