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

Mike Meyer mwm at mired.org
Wed Jul 6 22:47:30 EDT 2005


Ron Adam <rrr at ronadam.com> writes:
> 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.

So how do I pass None to a function?

>      >>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

Why? Shouldn't it delete x?

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

I don't think so. I've programmed in langauges that gave undefined
variables a value rather than an exception. It almost inevitabley led
to hard-to-find bugs.

FORTRAN used to give all variables a type, so that a typo in a
variable name could well lead to a valid expression. The technic for
disabling this was baroque ("IMPLICIT BOOLEAN*1 A-Z"), but so common
they invented a syntax for it in later versions of FORTRAN ("IMPLICIT
NONE").

         <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list