[Python-ideas] parameter omit

[Aaron Brady]

> -----Original Message-----
> From: Jan Kanis [mailto:jan.kanis at phil.uu.nl]
> Sent: Friday, May 11, 2007 6:59 AM
> 
> 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>

Not only does the OP's proposal (me) exonerate programmers who have screwed
up before, those who have neglected to use None for defaults, and who chose
meaningful ones instead, but encourages them to continue to choose it, and
frees them from checking the parameter later.

> From: Leonardo Santagada
> i'm like -1000 on it... or
> 
> def vote(who, value=-1000):
-1000: well within expected parameters.  <Snick>

Note DefaultArg needs never get referenced literally in declarations, only
in calls.

def ghi( j=None, k=None, l=None ):
	if j is None: j= Something
	if k is None: k= Something2
	if l is None: l= Something3

No.  Here, I do it all at once.
def ghi( j=Something, k=Something2, l=Something3 ):

Calls like ghi( MyThing ) still work, as does:
ghi( MyThing, l=MyThing3 ).

Everybody's on board so far and nothing's changed.  Omissions, positional,
and keyword arguments still work as we've grown to know and love.

What we can do, is always know the parameter.  The change is to know the
default value in every situation.  It's always DefaultArg.

ghi( MyThing, DefaultArg, Mything3 )
as well as
ghi( DefaultArg, MyThing2 )

Nothing breaks; everything that used to work still does.  There's no magic
in my proposal, no more than defaults create in the first place.  Functions
get the assignments done for them; they take no extra logic on their own.

It's completely backwards compatible.  No question there!  But you get new
abilities too, for the price of something that's unobtrusive and blends
right in.

To address Jewett, default arguments -are- built into bytecode.  The wrapper
takes a single memory address comparison on a per-argument basis.  It could
get expensive, but at least compare it to looking up values in dictionaries,
which is quite common.

> > DefaultArgument - Special value used in remaining cases of default
> > arguments
> > where None is otherwise meaningful.  New in version 2.6.

If they're not defined, as in C code, then they're always last, or couldn't
be called like you guys want to anyway.  Raise the usual exception anyway.

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

Agreed entirely.  You mean, like this?

Who brings up the manual?  Good.  Document something.

Your names in lights, I can see it now.  I'll write the PEP, but first stop
pointing out drawbacks and motivate me.  Wink( DefaultArg ).

P.S.
> 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>
Nonsense.  I'll have my people call my people immediately re: mailing list
people.  A little louder and stronger could suffice.  "Let me hear it son.
Costs and benefits.  Bottom line.  Assets or liabilities?"  Then put your
feet up.