Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!feeder2.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.009 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'argument': 0.05; 'defaults': 0.07; 'received:198': 0.07; 'variables': 0.07; 'arguments': 0.09; 'arguments,': 0.09; 'cc:addr:python-list': 0.11; 'def': 0.12; "%s'": 0.16; '+1.': 0.16; 'definition.': 0.16; 'merely': 0.16; 'mutable': 0.16; 'namespace.': 0.16; 'do.': 0.18; 'seems': 0.21; 'cc:addr:python.org': 0.22; 'cc:2**0': 0.24; 'references': 0.26; 'least': 0.26; 'header:In-Reply-To:1': 0.27; 'function': 0.29; 'words': 0.29; 'nature': 0.30; "i'm": 0.30; 'changed.': 0.31; 'initialized': 0.31; 'bugs': 0.33; 'problem': 0.35; 'one,': 0.35; 'but': 0.35; 'described': 0.36; 'everyone.': 0.36; 'keyword': 0.36; 'received:gov': 0.36; 'skip:j 20': 0.36; 'charset:us-ascii': 0.36; 'changing': 0.37; 'track': 0.38; 'rather': 0.38; 'skip:o 30': 0.61; 'entire': 0.61; 'name': 0.63; 'to:addr:gmail.com': 0.65; 'worth': 0.66; 'caused': 0.69; 'default': 0.69; 'obvious': 0.74; 'behavior': 0.77; 'subject:Value': 0.84 From: "Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC]" To: Ian Kelly Date: Thu, 20 Jun 2013 17:28:06 -0500 Subject: Re: Default Value Thread-Topic: Default Value Thread-Index: Ac5uBW9dw2YRGmlvTKOIEf06iqHIYg== References: <7e6361d5-6619-4aaa-adda-8b5f01bde57f@googlegroups.com> <447dd1c6-1bb2-4276-a109-78d7a067b442@d8g2000pbe.googlegroups.com> <2e92b4c7-31be-40d2-a906-ab19f3630dfa@googlegroups.com> <09cfa648-ab87-4261-b8f0-bf493de00553@4g2000pbf.googlegroups.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5779B3B4A736433FB8D2FB36A425651Bnasagov_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-20_09:2013-06-20, 2013-06-20, 1970-01-01 signatures=0 X-Mailman-Approved-At: Fri, 21 Jun 2013 13:00:12 +0200 Cc: Python X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 64 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1371812413 news.xs4all.nl 15905 [2001:888:2000:d::a6]:45898 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:48858 --_000_5779B3B4A736433FB8D2FB36A425651Bnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Or, in many MANY cases, the choice was the right one, but isn't obvious to everyone. I think it's worth pointing out that changing function defaults to late-binding would merely change the nature of the gotcha, not eliminate it= . words =3D ("one", "two", "red", "blue", "fish") def join_strings(strings=3Dwords): return ' '.join('%s %s' % (s, strings[-1]) for s in strings[:-1]) # Later: words =3D open("gettysburg_address.txt", "r").read().split() # Oops, the default argument of join_strings just changed. +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 argument= s, at least you know the cause is in the function definition. If you initia= lized variables each time, you'd have to track the problem down across the = entire namespace. I, for one, would much rather follow the rule "don't use mutable arguments = in function definitions" than "don't ever re-use the name of your variables= ." ML --_000_5779B3B4A736433FB8D2FB36A425651Bnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Or, in many MANY cases, the choice was = the right one, but isn't
obvious = to everyone.

I think it's worth pointing out that chang= ing function defaults to
late-binding would merely change the nature of = the gotcha, not eliminate it.

words =3D ("one", "two", "red", "blue"= , "fish")

def join_strings(strings=3Dwords):
   r= eturn ' '.join('%s %s' % (s, strings[-1]) for s in strings[:-1])

# L= ater:
words =3D open("gettysburg_address.txt", "r").read().split()
# = Oops, the default argument of join_strings just changed.
=

+1. This is what convinces me that keeping references to key= word 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&nbs= p;track down and understand than any bugs caused by mutable arguments. With= mutable arguments, at least you know the cause is in the function definiti= on. If you initialized variables each time, you'd have to track the problem= down across the entire namespace.

I, for one, wou= ld much rather follow the rule "don't use mutable arguments in function def= initions" than "don't ever re-use the name of your variables."
ML
= --_000_5779B3B4A736433FB8D2FB36A425651Bnasagov_--