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