Default Value

[Rick Johnson]

On Friday, June 21, 2013 6:40:51 PM UTC-5, Rotwang wrote:
> On 21/06/2013 19:26, Rick Johnson wrote:
> [...]
> I didn't ask what alternative methods of handling default
> argument binding exist (I can think of several, but none
> of them strikes me as preferable to how Python currently
> does it). I asked what would happen in /your/ version of
> Python. Which of the alternatives that you present would
> have been implemented, if you had designed the language?

The apathetic approach. However, you fail to understand that
whilst Python's current implementation is partly apathetic,
is is also benevolent, and malevolent simultaneously. My
approach is purely apathetic. I'll explain later. Stay
tuned.

> [...]
> So how does the interpreter know whether an arbitrary
> object passed as a default value is mutable or not? Not
> that it really matters.

Well i'm glad it does not matter to you because it does not
matter to me either. *shrugs*

> > Let's imagine for a second if Python allowed mutable keys in
> > a dictionary,
> which it does

Am i just to take your word for this? You cannot provide an
example? Here, allow me to "break the ice":

    # Literal
    py> d = {[1]:2}
    Traceback (most recent call last):
      File "<pyshell#0>", line 1, in <module>
        d = {[1]:2}
    TypeError: unhashable type: 'list'
    # Symbol
    py> lst = [1]
    py> d = {lst:2}
    Traceback (most recent call last):
      File "<pyshell#2>", line 1, in <module>
        d = {lst:2}
    TypeError: unhashable type: 'list'

Hmm, maybe only certain mutables work? Great, more esoteric
rules! Feel free to enlighten me since i'm not going to
waste one second of my time pursuing the docs just to learn
about ANOTHER unintuitive PyWart i have no use for.

> Now, I don't really believe that you think that the user
> shouldn't be protected from doing one idiotic thing with
> mutable dict keys but should be protected from doing
> another idiotic thing with mutable default arguments,
> especially as you've already been given a use case for the
> latter. So I assume that The Benevolent Approach is not
> the approach you would have gone for if you had designed
> the language, right? If so then let's ignore it.

You are correct. Finally, we can agree on something.

> > ============================================================
> >   The Apathetic Approach:
> > ============================================================
> > I could just assume that a programmer is responsible for the
> > code he writes. If he passes mutables into a function as
> > default arguments, and then mutates the mutable later, too
> > bad, he'll understand the value of writing solid code after
> > a few trips to exception Hell.
>
> It seems to me that this is exactly what currently happens.

(is this lazy readers day? I swear i explained this earlier)

And here is where you are wrong. In the current implementation
python functions carry the state of mutable default arguments
between successive calls. That's a flaw. Observe:

    py> def foo(arg=[]):
    ...     arg.append(1)
    ...     print(arg)
    ...
    py> foo()
    [1]
    py> foo()
    [1, 1]
    py> foo()
    [1, 1, 1]

No, no, NO! That's wrong! Subroutines should be stateless.
That means that an empty mutable default argument will
ALWAYS be empty at each call of the subroutine.  This is
what should happen:

    py> def foo(arg=[]):
    ...     arg.append(1)
    ...     print(arg)
    ...
    py> foo()
    [1]
    py> foo()
    [1]
    py> foo()
    [1]

Yes, Yes, YES! That is intuitive! That is sane! Now, what if
we pass a reference to a mutable object? What then. Well, let's
see:

    py> lst = range(5)
    py> lst
    [0, 1, 2, 3, 4]
    py> def foo(arg=lst):
    ...     arg.append(1)
    ...     print(arg)
    ...
    py> foo()
    [0, 1, 2, 3, 4, 1]
    py> foo()
    [0, 1, 2, 3, 4, 1, 1]

That's fine. Because the object was already created OUTSIDE
the subroutine. So therefore, modifications to the mutable
are not breaking the fundamental of statelessness INSIDE
subroutines. The modification is merely a side effect, and
the subroutine is unconcerned with anything that exists
beyond it's own scope.

IS ALL THIS REGISTERING YET? DO YOU UNDERSTAND?

> > ============================================================
> >   The Malevolent Approach (disguised as beneva-loon-icy):
> > ============================================================
> > I could use early binding to confuse the hell out of him and
> > enjoy the laughs with all my ivory tower buddies as he falls
> > into fits of confusion and rage. Then enjoy again when he
> > reads the docs. Ahh, the gift that just keeps on giving!
> My question was about how you think the language should
> work, not about what your buddies should or shouldn't
> enjoy.

My buddies? This design flaw is NOT my brain child. Your
barking up the wrong tree pal.

> In terms of how a language actually works, is there
> any difference between The Malevolent Approach and The
> Apathetic Approach? And is there any difference between
> either of them and what Python currently does?

I explained this to MRAB already.

> Of course using a mutable default as a cache can be
> reproduced by other means, as can another common use case
> that I don't think anyone's mentioned yet (defining
> functions parametrised by variables whose values aren't
> known until runtime). That's hardly an argument against it
> - you might as well argue that Python shouldn't have
> decorators, or that it shouldn't have for loops because
> their behaviour can be reproduced with while loops.

Nice attempt at sleight of hand but your logic is clumsy.

Your trying to argue that my use of a "custom callable state
object" (to avoid the esoteric and unintuitive nature of the
current implementation of Python "mutable function
arguments") is somehow only a mere reproduction of the
function behavior and has no positive benefits, when in
fact, it has a HUGE direct benefit:

 * AVOIDING A FLAW IN THE LANGUAGE

It also has quite a few positive side effects:

 * CODE ENCAPSULATION
 * INTERFACE
 * USING THE CORRECT TOOL FOR THE JOB++
 * READABILITY
 * NO HIDDEN SURPRISES
 * LESS BUGGY

How much more justification do you need?

> or that it shouldn't have for loops because their
> behaviour can be reproduced with while loops.

Yes, iterating a sequence can be achieved using a "while
loop", but "for loops" should not be thrown out because they
offer a specific type of iteration that nicely complements a
while loop. Plus, for loops do not have any strange side
effects (unlike Python functions). They do one thing and
they do damn well! So stop picking on for loops :-)

I want Python functions to also "do one thing and do it
well", and what is that "one thing" you ask, execute
subprograms.

> But this is beside the point anyway, until you present an
> alternative to Python's current behavior. If you do so
> then we can start debating the relative merits of the two
> approaches.

The fix is simple. No more "magical Python functions", only
stateless routines. I've explained this ad nauseam already,
and until you provide more specific questions on the matter,
i refuse to reply to any more bombastically general questions.