On 4/19/07, Steven Howe <[EMAIL PROTECTED]> wrote: > > Steven D'Aprano wrote: > On Thu, 19 Apr 2007 08:18:30 -0400, Steve Holden wrote: > > > > > Which is why I suggested using the explicit type(x) == types.NoneType as > opposed to > x is None > > > > This seems to go entirely against the spirit of the language. It's about > as sensible as writing > > (3 > 4) == True > > > Please! For extra certainty, you should write that as: > > ((int(3) > int(4)) == True) == True > > Explicit is better than sensible, yes? > > *wink* > > > > > Your example, even with the *wink*, is stupid. The language requires 3 to > be an integer, 4 to be an integer. > > > The point I was show is with respect to a returned variable (like from a > function or method? *wink* *wink*). > For example, if you expect an open file handle, but get a NoneType because > you didn't really open a file (having given a bad name or maybe didn't have > permission to open a file),
This won't happen, because an exception will be thrown instead. But if it *did*, you'd test with "is None", not by type comparison. >then it would be best to test the type of return > object before using it. Then you program could handle the error gracefully > (*wink* *wink* *wink*). > > As much as I love Python, it's ability to morph an object type can be a > pain. Testing before using can prevent a program from Error-ing out. > This is contrary to the vast majority of Python philosophy. Embracing rather than fighting it will result in a much more pleasant Python experience. > Steven Howe > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
