Default Value

[Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC]]

On Jun 21, 2013, at 11:17 AM, Rick Johnson wrote:

> On Thursday, June 20, 2013 5:28:06 PM UTC-5, Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC] wrote:
>> 
>> [snip example showing dummy coder doing something dumb]
>> 
>> +1. This is what convinces me that keeping references to
>> keyword arguments is actually the right thing to do.
>> 
>> Perhaps I'm biased because I'm used to the mutable-
>> argument behavior by now, but the gotcha described above
>> seems to be much harder to track down and understand than
>> any bugs caused by mutable arguments. With mutable
>> arguments, at least you know the cause is in the function
>> definition. If you initialized variables each time, you'd
>> have to track the problem down across the entire
>> namespace.
> 
> That's because you and many other folks, who keep supporting
> this BS idea, have become SO accustomed to writing code in a
> sloppy manner, that you need this flaw to save yourself,
> FROM YOURSELF!

Look, this list has enough problems with trolling and flame wars already. The people debating in this thread have generally been respectful to you, have put forward valid points, and are interested in an intellectual debate. Please treat other people with respect and we will have an easier time listening to your points. You have no idea whether my or anyone else's code is sloppy, and you are objecting to a *language feature*, not a coding style.

The "[snip example showing dummy coder doing something dumb]" was not something dumb at all. Sometimes, people re-use variable names. Sometimes, people do that even at the module level. In a large module, I don't have the mental RAM to keep track of every single variable name I've used. It happens to the best of us.

The point we're making is that Python is a dynamic language. That is a non-negotiable feature of the language. Lookup of the value of a variable happens dynamically. The underlying object may not be mutable, but the value of a variable is. Variables change. If your argument is that Python should have a "final" or "const" keyword to prevent certain variables from changing, then that's a different story.

The semantics you are proposing would necessarily imply that the lookup of a variable has to happen every time you call a function. And since variables change—even if the variables point to immutable objects—the value of a default argument could change.

> " Hello, allow myself to introduce myself"
> 
> Apparently you don't understand the value of writing rock
> solid code. Instead of passing your mutables in as
> arguments, all you have to do is reference them properly in
> the BODY of the subroutine and everything will work just
> fine. If you fear global level variables then write up a
> simple Object definition to encapsulate the mutable and make
> it callable.

In general, of course you want to pass mutables as arguments to a Python function. That's the basis of every method call in python—the first argument, `self`, is mutable.

And we're not talking about passing mutables in as arguments, we're talking about the *default* values of arguments that sometimes happen to be mutable. And sometimes that's useful. Let's say you have a function that has some sort of logging functionality, and you usually want to use the module default logger, but sometimes you can pass in another logger. (And we assume that our loggers are stateful, perhaps keeping track of lines written.) In order to have this functionality, you have to treat the logger as an argument.

> ============================================================
> Thought Exercise:
> ============================================================
> 
> Let's imagine for a second if Python allowed mutable keys in
> a dictionary, would you be surprised if you used a mutable
> for a key, then you mutated the mutable key, then you could
> not access the value from the original key? 
> 
> ## Imaginary code ##
> py> lst = [3]
> py> d = {1:2, lst:4}
> py> lst.append(10)
> py> d[lst]
> opps, KeyError!
> 
> Would you REALLY be so surprised? I would not. But more
> importantly, does Python need to protect you from being such
> an idiot? I don't think so!
> 
> Any "intelligent" programmer would NEVER use mutable keys
> for a hash table -- unless he had a very good reason and was
> willing to take the risks -- EVEN IF the language allowed
> such foolishness!

The reason this isn't allowed is because the concept of "hashing" an object whose state changes is conceptually incoherent (given the normal uses of hashing). Having a mutable default value for a function is a coherent concept with a number of possible use cases, although it does happen to trip up beginners sometimes.

>> I, for one, would much rather follow the rule "don't use
>> mutable arguments in function definitions"
> 
> Yes, that's the exact point i'm making! A little self
> discipline can go a long way

No, that's not the point you're making. I'm putting the responsibility on the programmer to follow this rule, and giving her the freedom to break it when she sees fit and when she knows what she's doing. You're saying "don't even allow mutable arguments in function definitions" and putting the responsibility on the language designers. I'm sorry if there was a miscommunication on that point.

>> than "don't ever re-use the name of your variables."
> 
> Well, we're not even talking about that, but i understand
> the value of your statement. Although, i think your
> comparing Apples and Oranges.

No, you're not talking about that directly. The point I was making, supported by Ian Kelly's example, was that the new semantics you are talking about would necessarily imply a new gotcha, one which would result in the rule "don't re-use the name of your variables." I find that to be a much more sinister "gotcha" than the current one.

> 
> PS: First you support the opposition. now you go an do a
> 180? You're confusing the hell out of me Matthew! @_@
> -- 
> http://mail.python.org/mailman/listinfo/python-list

All in all, if you have a real objection to this and have a constructive proposal for improvement, you should submit it to Python-Ideas, perhaps discussing it here before proposing it there. If you are confused about this feature and are willing to believe that maybe, just maybe, the inventors of the Python language know a little bit more about designing the semantics of a language than you do, then feel free to continue this thread and we'll all have a learning experience. If you are only trying to say that you dislike this feature therefore Python is a shoddily-constructed language, feel free to use Haskell.

So, what better semantics would you propose, exactly?

I see a few options at first, but there are certainly more. Feel free to add your own proposal.

1. Disallow all mutable arguments as parameters of functions. This would lead to a fundamental change in Python, since (see my point above) Python objects require the first argument to every method is the mutable `self` argument.

2. Disallow all mutable arguments as default values of keyword parameters. This might work, but what if you use a variable? And what if the value variable is dependent on other things happening in the module? (Remember, variables are dynamically typed). All of a sudden, code that worked in one instance might not work in another.

3. Re-initialize all keyword argument values every time the function is called. This leads to more function call overhead, and generates the surprises that I, Ian Kelly, and several other posters have pointed out. These gotchas are equally as frustrating.

4. Re-initialize all keyword argument values every time the function is called, but only if they happen to be literals. This breaks the principle of least astonishment, IMO, since it creates a fundamental difference between the ways literals and variables are processed.

5. Introduce a "const" keyword and then only allow const variables as default argument variables… Maybe that's a good idea. I'll let others chime in.

What approach do you support? One of the above? None of the above?