[Python-ideas] parameter omit

[Jan Kanis]

On Fri, 11 May 2007 10:43:18 +0200, Aaron Brady <castironpi at comcast.net>  
wrote:

>> -----Original Message-----
>> From: python-ideas-bounces at python.org [mailto:python-ideas-
>> bounces at python.org] On Behalf Of Aaron Brady
>>
>> > [snip]
>
> Your stewardship is remarkable.  But in the case I mention, the costs  
> aren't
> worth mention.  It's an outstanding case, for clear, cost-free, net  
> benefit.
> Say the parameter is required to be callable.  `None' will not suffice.   
> The
> strongest case against me is that I enable lazy programmers to make
> assignments in the function declaration.  That's worth bringing up.   
> OTOH,
> what if None is the wrong default?
>
> 2.4 Built-in Constants
> A small number of constants live in the built-in namespace. They are:
>
> False - The false value of the bool type. New in version 2.3.
>
> True - The true value of the bool type. New in version 2.3.
>
> None - The sole value of types.NoneType. None is frequently used to
> represent the absence of a value, as when default arguments are not  
> passed
> to a function.
>
> NotImplemented - Special value which can be returned by the ``rich
> comparison'' special methods (__eq__(), __lt__(), and friends), to  
> indicate
> that the comparison is not implemented with respect to the other type.
>
> Ellipsis - Special value used in conjunction with extended slicing  
> syntax.
>
> DefaultArgument - Special value used in remaining cases of default  
> arguments
> where None is not what is intended.
>
> Does one complain about Ellipsis?  No, it's useful.  Comes in handy at  
> just
> the right times.
>
> And furthermore, this proposal isn't entirely without precedent.
>

There are some hidden costs you haven't mentioned yet:
1) It's another paragraph in the manual.
2) If DefaultArgument is just a normal object in the builtin namespace,  
without any interpreter magic every function using default values would  
have to use some logic to recognize DefaultArgument and do the right  
thing. If there is interpreter magic that'll be more magic, and another  
section in the manual to explain that. (apart from magic in itself being  
bad)

A small manual addition wouldn't be a problem on its own, but proposals  
that easily fix some use case with just a single paragraph manual addition  
pass by every other week. If they'd all be accepted we'd be saving  
ourselves a lot of trouble by switching to Perl immediately. More manual  
means more language complexity, another little step for people learning  
python, and another page of brain cell usage for anyone using Python.

In short, any new addition has to have a *lot* of utility to be  
acceptable, or else it wil lead to the way of the Perl side.

- Jan

Oh, and having jerks around is an unfortunate & unintended side effect of  
having people in the mailing list. I'd be interested if you had any ideas  
to diminish the problem, though. <wink>