map/filter/reduce/lambda opinions and background unscientific mini-survey

Ron Adam rrr at ronadam.com
Wed Jul 6 15:20:15 EDT 2005


Dan Sommers wrote:

>>     AttributeError: 'NoneType' object has no attribute 'read'
> 
> 
> This is the one of which I was thinking.  So you see this error at the
> end of a (long) traceback, and try to figure out where along the (long)
> line of function calls I typed the wrong name.  Currently, the very end
> of the traceback points you right at the bad code and says "NameError:
> name 'filehandle' is not defined," which tells me (very nearly) exactly
> what I did wrong.

The actual error could be improved a bit to refer the the name of the 
and line the error is in.  Which would help some.

        AttributeError: 'NoneType' object "file_handle" has no attribute 
'read'


> I guess it depends on how long your traceback is and how big those
> functions are.  Also, from the Zen:
> 
>     Explicit is better than implicit.
> 
> although from previous threads, we know that every pythonista has his or
> her own definitions of "explicit" and "implicit."

True, but this isn't any different than any other 'Type' error, or value 
error.  And considerably easier to find than one off errors.

There would be more restrictions on None than there are now so it 
wouldn't be as bad as it seems.  For example passing a None in a 
function would give an error as the name would be deleted before the 
function actually gets it.

So doing this would give an error for functions that require an argument.

     def foo(x):
         return x

     a = None
     b = foo(a)    #  error because a dissapears before foo gets it.

     >>TypeError: foo() takes exactly 1 argument(0 given)


So they wouldn't propagate like you would expect.

Hmmm.... interesting that would mean... lets see.


    1. var = None            # removes ref var,  this is ok

    2. None = var            # give an error of course

    3. var = undefined_var   # same as "var = None",  that's a problem!

Ok... this must give an error because it would delete var silently! 
Definitely not good.  So going on, on that basis.

    4. undefined == None     # Special case, evaluates to True.

    5.  def foo():return None   # same as return without args

    6.  x = foo()            #  Would give an error if foo returns None

This might be an improvement over current behavior.  Breaks a lot of 
current code though.

    7.  if undefined:        # error

    8.  if undefined==None   #  Special case -> True

Good for checking if vars exist.

    9.  if undefined==False  #  Error, None!=False (or True)

    9.  while undefined:     # error

    10  while undefined==None:

Possible loop till defined behavior.


Ok... and undefined var returning None is a bad idea, but using None to 
del names could still work.  And (undefined==None) could be a special 
case for checking if a variable is defined.  Otherwise using an 
undefined name should give an error as it currently does.

Cheers,
Ron


> Regards,
> Dan




More information about the Python-list mailing list