map/filter/reduce/lambda opinions and background unscientific mini-survey
rrr at ronadam.com
Thu Jul 7 07:52:05 CEST 2005
Mike Meyer wrote:
> 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?
You wouldn't. What would a function do with it anyway? If you wanted
to pass a neutral value of some sort, then you'd just have to pick
something else and test for it. Maybe we could use Nil as an
alternative to None for that purpose?
>> 6. x = foo() # Would give an error if foo returns None
> Why? Shouldn't it delete x?
That was my first thought as well.
It would cause all sorts of problems. One way to avoid those is to
insist that the only way to assign (delete) a name to None is by
literally using "None" and only "None" on the right side of the = sign.
Any undefined name on the right side would give an error except for None
>>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.
That is why the above should give an error I believe. ;)
> 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
It's been so long since I did anything if Fortran I've actual don't
recall any of it. :) '83-'84
I went from that to pascal, which I thought was a big improvement at the
More information about the Python-list