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

Ron Adam 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 
itself.

>>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
> NONE").

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

Cheers,
Ron




More information about the Python-list mailing list