Default Value

M

MRAB

On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
My argument has always been that mutables should not be
passed into subroutines as default arguments because bad
things can happen. [...] I also believe that a programmer
should not be prevented from passing mutable default
arguments [...]
So, having mutables as default arguments is a bad idea,
but a programmer should not be prevented from doing that,
and a warning message should be printed on such occasions.

Well i'll admit that does sound like a contradiction.
Basically i meant, programmers should be *discouraged* from
passing mutables as default arguments but not *prevented*.
Of course, utilizing a stateless subroutine like i suggest,
argument mutability would not matter.

Sometimes when you're passionate about something your
explanations become so verbose as to render your idea lost
in the noise. Obviously i made that mistake here :)
Yes, a more measured explanation tends to work better. :)
In my last reply to Rotwang i explained the functionality i
seek to achieve in a set of three interactive examples.
Take a look at those and let me know what you think.
Hmm. Like they say, "The devil's in the details". As with the
mutability thing, I need to think about it some more. Sometimes it
seems straight-forward, until you try to do it! :)
Agreed. And i am thankful for everyone's contributions. I
can be a bit harsh sometimes but my intention has always
been to improve Python.


Well thanks for admitting you are not perfect. I know i am
not. We all had to start somewhere and anyone who believes
he knows everything is most assuredly a fool. Learning is
a perpetual process, same for software evolution.


I understand. We can't break backwards compatibility for
everything, even breaking it for some large flaws could
cause a fatal abandonment of the language by long time
users.

I just don't understand why i get so much hostility when i
present the flaws for discussion. Part of my intention is to
air the flaw, both for new users and old users, but a larger
intention is to discover the validity of my, or others,
possible solutions.
The problem is in _how_ you do it, namely, very confrontationally.
You call yourself "RantingRick". People don't like ranting!

Instead of saying "This is obviously a flaw, and you're a fool if you
don't agree", you should say "IMHO, this is a flaw, and this is how I
think it could be fixed". Then, if someone points out a problem in your
suggested fix, you can say "OK, I see your point, I'll try to see
whether I can think of a way around that". Etc.
 
D

Dennis Lee Bieber

Yes, that was the joke.

Given some of the personalities here, making sure the irony was
revealed could be useful...

Yes, I suspected it was humor... Some might have taken it literally.
 
R

Rotwang

============================================================
QUESTION 1:
============================================================

Well nothing could happen, or something significant could
happen. How do you expect me to determine an answer for
such a general question when i have no context, or any
algorithms to work from.

You don't have an algorithm to work from? I assumed you did. If you
don't have an algorithm in mind as an alternative to Python's existing
behaviour, then what exactly is your point?

Anyway, I already proposed an algorithm that is consistent with your
examples, in

http://mail.python.org/pipermail/python-list/2013-June/650447.html

.. Is that what you have in mind?

Maybe you are trying to set a situation that results in
chaos, okay, then chaos will happen.

No, I'm not. I'm simply trying to find out what alternative behaviour
you're proposing for Python, because the examples you've given so far
are not sufficient to explain what happens in the general case.

But who's fault is the
chaos when a programmer is rebinding names? The programmer
is ultimately responsible for his action.

Remember my "Apathetic Approach"?

============================================================
QUESTION 2:
============================================================
Does the default stay the same or does it change to the
new value of lst?

Here you go again, you cannot seem to comprehend very simple
concepts. My second example clearly explains what will happen
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]

No, it doesn't, because lst is not rebound in your second example. As
such, entering >>> lst = []; foo() could return [1], or it could return
[0, 1, 2, 3, 4, 1, 1, 1]. Both of those could result from behaviours
that gave the exact same output as the two examples you've given. It is
literally impossible for me to know what you would like to see happen in
this case from the limited information you've given me.

On the other hand, from the specification I gave earlier it's easy to
see that >>> lst = []; foo() would return [1]. Is this what you want?

Do you see how the name 'lst' is bound to a list object
living in global module scope? Do you see how the default
argument (named `arg`) is a reference to a global list named
`lst`?

ARE YOU FOLLOWING ALONG SO FAR?

Since the mutable arg exists OUTSIDE the subroutine, the
subroutine merely need to provide access to the global
*name* `lst` from within the body of the subroutine, and the
subroutine merely do this ONCE at compile time!

ARE YOU FAMILIAR WITH THE CONCEPT OF POINTERS?

Yes, but Python doesn't have them. Are you proposing that it should have
them, and that they should play some role in Python default binding
behaviour? If so then a better way of making people aware of this would
be to tell them, rather than expecting them to guess and then pretending
that their failure to do so represents some failing on their part.

============================================================
QUESTION 3-A:
============================================================

Hmm, let's have a thought experiment. What if i give you a
digital birthday card. And when you open the card you see a
friendly note from me:

"Rotwang is my best friend in the whole wide world".

But unbeknownst to you, i have actually hacked the card and
installed a secret wifi device. I've made the message
mutable -- hmm, surely nothing "bad" could arise from
mutability correct?

*evil-grin*

A few hours later when you open the card to show to some
friends, you are alarmed to see a new message:

"Rotwang is a degenerative penis condition"

Now, besides being embarrassed, and probably angry as hell,
do you understand the dangers of mutable objects?

Yes. As I expect you already know, I'm well aware of the dangers of
mutable objects. But that isn't what I'm asking you about. I'm asking
you what method you propose to avoid one of those dangers. Why don't you
just answer the question, instead of answering a different question I
didn't ask?

I'm not suggesting you don't ever want to use the power of
mutability, no, but you do need to have a healthy respect for
mutability -- because it can really ruin your day!

============================================================
QUESTION 3-B:
============================================================

If the argument is an expression, like a literal, it will be
reset to the literal each time the subroutine is called. If
the argument is a non-local object, the argument will NOT be
reset each time.

Notice how neither of those answers the question I asked? I asked what
happens when the argument is a call.

============================================================
QUESTION 3-C:
============================================================

What if X?
What if Y?
What i pass in a pony but i sell it to a glue factory before
the subroutine gets called???

I'm sorry but have no more patience for these ridiculous
questions. If you want me to answer *specific* questions, then
be sure to ask them one at a time and provide relevant code
examples.

Please answer the question I asked in

http://mail.python.org/pipermail/python-list/2013-June/650447.html

..
 
G

Grant Edwards

On 21/06/2013 21:44, Rick Johnson wrote: [...]
Which in Python would be the "MutableArgumentWarning".

*school-bell*

I notice that you've omitted any mention of how you'd know that the
argument was mutable.

That's easy. Just call ismutable(arg). The implementation of ismutable is
just an implementation detail, somebody else can work that out. A
language designer of the sheer genius of Rick can hardly be expected to
worry himself about such trivial details.

While we're at it, I would like to petition for a function
terminates(f, args) that I can use to determine whether a function
will terminate before I actually call it.

I think it should be terminate_time() -- so you can also find out how
long it's going to run. It can return None if it's not going to
terminate...
 
M

MRAB

On Fri, 21 Jun 2013 23:49:51 +0100, MRAB wrote:

On 21/06/2013 21:44, Rick Johnson wrote:
[...]
Which in Python would be the "MutableArgumentWarning".

*school-bell*

I notice that you've omitted any mention of how you'd know that the
argument was mutable.

That's easy. Just call ismutable(arg). The implementation of ismutable is
just an implementation detail, somebody else can work that out. A
language designer of the sheer genius of Rick can hardly be expected to
worry himself about such trivial details.

While we're at it, I would like to petition for a function
terminates(f, args) that I can use to determine whether a function
will terminate before I actually call it.

I think it should be terminate_time() -- so you can also find out how
long it's going to run. It can return None if it's not going to
terminate...
Surely that should be float("inf")! Anything else would be ridiculous!
:)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,021
Latest member
AkilahJaim

Latest Threads

Top