Should Python raise a warning for mutable default arguments?

**Steven D'Aprano** · Aug 23 '08, 01:55 AM

Re: Should Python raise a warning for mutable default arguments?

On Fri, 22 Aug 2008 14:39:11 -0700, Emile van Sebille wrote:

Dan wrote:

>I'd suggest that at the
>end of the tutorial, when people have a better general idea of how
>Python works, there would be a Python Gotchas section.
>>
>>

Hmmm, OK -- mutable defaults, integer division, name mangling...
>
I'd think decimal precision is more a general problem than a python
problem, but still one that throws newbies...
>
Any other ideas for gotcha's (as opposed to faqs)?

Augmented assignment: x ?= y is not always the same as x = x ? y.

Repeated string addition can be very slow. For that matter, so can list
addition.

Inserting at the beginning of lists is slow.

Everything about unicode is a Gotcha! *wink*

Raw strings are not designed for Windows paths, they're designed for
regexes. Consequently, you can't write the following:

r'C:\dir\'

list.sort() and list.reverse() return None.

sorted() returns a list, but reversed() returns an iterator.

urllib2.urlopen () will automatically detect the proxy in your environment
and use that. That's usually a feature, but sometimes it can be a gotcha.

urllib2 doesn't work well with some HTTPS proxies. This is, I believe, a
known bug, but until it is fixed, it can be a gotcha.

--
Steven

**George Sakkis** · Aug 23 '08, 03:15 AM

Re: Should Python raise a warning for mutable default arguments?

On Aug 22, 9:54 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Fri, 22 Aug 2008 14:39:11 -0700, Emile van Sebille wrote:

Dan wrote:

I'd suggest that at the
end of the tutorial, when people have a better general idea of how
Python works, there would be a Python Gotchas section.

>

Hmmm, OK -- mutable defaults, integer division, name mangling...

>

I'd think decimal precision is more a general problem than a python
problem, but still one that throws newbies...

>

Any other ideas for gotcha's (as opposed to faqs)?

>
Augmented assignment: x ?= y is not always the same as x = x ? y.
>
Repeated string addition can be very slow. For that matter, so can list
addition.
>
Inserting at the beginning of lists is slow.
>
Everything about unicode is a Gotcha! *wink*
>
Raw strings are not designed for Windows paths, they're designed for
regexes. Consequently, you can't write the following:
>
r'C:\dir\'
>
list.sort() and list.reverse() return None.
>
sorted() returns a list, but reversed() returns an iterator.
>
urllib2.urlopen () will automatically detect the proxy in your environment
and use that. That's usually a feature, but sometimes it can be a gotcha.
>
urllib2 doesn't work well with some HTTPS proxies. This is, I believe, a
known bug, but until it is fixed, it can be a gotcha.

My "favorite": comparisons between disparate types are allowed by
default. Thankfully fixed in 3.0.

George

**Carl Banks** · Aug 23 '08, 03:45 AM

Re: Should Python raise a warning for mutable default arguments?

On Aug 22, 10:42 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

Sometimes it seems that barely a day goes by without some newbie, or not-
so-newbie, getting confused by the behaviour of functions with mutable
default arguments. No sooner does one thread finally, and painfully, fade
away than another one starts up.
>
I suggest that Python should raise warnings.Runtim eWarning (or similar?)
when a function is defined with a default argument consisting of a list,
dict or set. (This is not meant as an exhaustive list of all possible
mutable types, but as the most common ones that I expect will trip up
newbies.) The warning should refer to the relevant FAQ or section in the
docs.
>
What do people think?

-1

There's nothing questionable about using a mutable default argument,
as long as you don't mutate it. Python shouldn't raise a warning just
because something *might* be due to a misunderstandin g.

I usefully use mutable default arguments all the time. Most commonly
in situations like this:

def f(data,substitu tions = {}):
...
name = data['name']
obj.name = substitutions.g et(name,name)
...

-0 on adding a warning that's disbaled by default.

Carl Banks

**Paddy** · Aug 23 '08, 04:05 AM

Re: Should Python raise a warning for mutable default arguments?

On Aug 22, 4:55 pm, Peter Otten <__pete...@web. dewrote:

bearophileH...@ lycos.com wrote:

DrScheme is an implementation of Scheme that is very newbie-friendly.
It has several limited sub-languages, etc.

>

So maybe a command line option can be added to Python3 ( -
newbie ? :-) ) that just switches on similar warnings, to help newbies
(in schools, where there's a teacher that encourages to always use
that command line option) avoid some of the most common traps.

>
Or maybe bundle pychecker with idle?
>
$ cat tmp.py
def test(x, a=[]):
a.append(x)
return a
>
for i in range(5):
print test(i)
>
$ pychecker tmp.py
Processing tmp...
[0]
[0, 1]
[0, 1, 2]
[0, 1, 2, 3]
[0, 1, 2, 3, 4]
>
Warnings...
>
tmp.py:2: Modifying parameter (a) with a default value may have unexpected
consequences
>
Though it might be interesting to ask a newbie what he expects when warned
of "unexpected consequences" ;)
>
Peter

+1 on this.

It seems an obvious think to add to a lint-like tool rather than
burdening core Python.

- Paddy.

**Steven D'Aprano** · Aug 23 '08, 08:15 AM

Re: Should Python raise a warning for mutable default arguments?

On Fri, 22 Aug 2008 20:37:09 -0700, Carl Banks wrote:

On Aug 22, 10:42Â am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

>Sometimes it seems that barely a day goes by without some newbie, or
>not- so-newbie, getting confused by the behaviour of functions with
>mutable default arguments. No sooner does one thread finally, and
>painfully, fade away than another one starts up.
>>
>I suggest that Python should raise warnings.Runtim eWarning (or
>similar?) when a function is defined with a default argument consisting
>of a list, dict or set. (This is not meant as an exhaustive list of all
>possible mutable types, but as the most common ones that I expect will
>trip up newbies.) The warning should refer to the relevant FAQ or
>section in the docs.
>>
>What do people think?

>
-1
>
There's nothing questionable about using a mutable default argument, as
long as you don't mutate it.

There's nothing questionable about using a mutable default argument, so
long as you know what behaviour to expect. I too use that behaviour, I
like that behaviour, and I'm tired of people who want it "fixed".

Nevertheless, it is surprising to many people. My aim is to make it a
little less surprising.

Python shouldn't raise a warning just
because something *might* be due to a misunderstandin g.

That's one opinion.

As I've eluded to in an early post, I don't believe Python should refuse
to perform an operation just because it might be slow. Nevertheless,
that's precisely what the sum() function does. I'm suggesting a warning
rather than an exception, but other than that, I suggest that there's
precedence to what I am suggesting.

--
Steven

**=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=** · Aug 23 '08, 01:45 PM

Re: Should Python raise a warning for mutable default arguments?

2008/8/22 Peter Otten <__peter__@web. de>:

bearophileHUGS@ lycos.com wrote:
>

>DrScheme is an implementation of Scheme that is very newbie-friendly.
>It has several limited sub-languages, etc.
>>
>So maybe a command line option can be added to Python3 ( -
>newbie ? :-) ) that just switches on similar warnings, to help newbies
>(in schools, where there's a teacher that encourages to always use
>that command line option) avoid some of the most common traps.

>
Or maybe bundle pychecker with idle?

I think that is an excellent idea! In fact why can't pychecker be
included in the standard distribution? I'd love it if compilation was
done with pychecker checking by default. Python could definitely use a
-Wall mode.

--
mvh Björn

**Carl Banks** · Aug 23 '08, 02:45 PM

Re: Should Python raise a warning for mutable default arguments?

On Aug 23, 4:09 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

On Fri, 22 Aug 2008 20:37:09 -0700, Carl Banks wrote:

On Aug 22, 10:42 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:

Sometimes it seems that barely a day goes by without some newbie, or
not- so-newbie, getting confused by the behaviour of functions with
mutable default arguments. No sooner does one thread finally, and
painfully, fade away than another one starts up.

>

I suggest that Python should raise warnings.Runtim eWarning (or
similar?) when a function is defined with a default argument consisting
of a list, dict or set. (This is not meant as an exhaustive list of all
possible mutable types, but as the most common ones that I expect will
trip up newbies.) The warning should refer to the relevant FAQ or
section in the docs.

>

What do people think?

>

-1

>

There's nothing questionable about using a mutable default argument, as
long as you don't mutate it.

>
There's nothing questionable about using a mutable default argument, so
long as you know what behaviour to expect. I too use that behaviour, I
like that behaviour, and I'm tired of people who want it "fixed".
>
Nevertheless, it is surprising to many people. My aim is to make it a
little less surprising.
>

Python shouldn't raise a warning just
because something *might* be due to a misunderstandin g.

>
That's one opinion.

1. When you print spurious warnings, the overall effectiveness of the
warning system is diminished. People start to ignore them, either by
disabling them or by mentally tuning out. This in turn makes people
less likely to notice if a real warning is printed.

When you print a warning, you better be %99.9 sure that it's something
worth warning about, otherwise you are doing more harm than good.

(Story time: I once worked on a system that displayed warnings to jet
fighter pilots. Our requirements were not to show the pilot a warning
unless the airplane actually tries something and fails, even if the
computer is absolutely sure that it would fail. Ex: if computer knows
for sure the engine can't produce more than (say) 50% rated thrust,
the pilot does not get a warning unless he actually requests more than
50% thrust. The reason is for this, according to the senior engineers
on the team, was that pilots would start to ignore the warning lights
REALLY FAST.)

2. It's rude to be presumptuous, which is what the compiler would be
if it printed this warning.

Carl Banks

**castironpi** · Aug 23 '08, 06:45 PM

Re: Should Python raise a warning for mutable default arguments?

On Aug 23, 9:40 am, Carl Banks <pavlovevide... @gmail.comwrote :

On Aug 23, 4:09 am, Steven D'Aprano <st...@REMOVE-THIS-
>
>
>
cybersource.com .auwrote:

On Fri, 22 Aug 2008 20:37:09 -0700, Carl Banks wrote:

On Aug 22, 10:42 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com .auwrote:
>Sometimes it seems that barely a day goes by without some newbie, or
>not- so-newbie, getting confused by the behaviour of functions with
>mutable default arguments. No sooner does one thread finally, and
>painfully, fade away than another one starts up.

>

>I suggest that Python should raise warnings.Runtim eWarning (or
>similar?) when a function is defined with a default argument consisting
>of a list, dict or set. (This is not meant as an exhaustive list of all
>possible mutable types, but as the most common ones that I expect will
>trip up newbies.) The warning should refer to the relevant FAQ or
>section in the docs.

>

>What do people think?

>

-1

>

There's nothing questionable about using a mutable default argument, as
long as you don't mutate it.

>

There's nothing questionable about using a mutable default argument, so
long as you know what behaviour to expect. I too use that behaviour, I
like that behaviour, and I'm tired of people who want it "fixed".

>

Nevertheless, it is surprising to many people. My aim is to make it a
little less surprising.

>

Python shouldn't raise a warning just
because something *might* be due to a misunderstandin g.

>

That's one opinion.

>
1. When you print spurious warnings, the overall effectiveness of the
warning system is diminished. People start to ignore them, either by
disabling them or by mentally tuning out. This in turn makes people
less likely to notice if a real warning is printed.
>
Carl Banks