Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Fri, 21 Jun 2013 20:25:49 +0100
From: MRAB <python@mrabarnett.plus.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Default Value
References: <7e6361d5-6619-4aaa-adda-8b5f01bde57f@googlegroups.com> <b3d90d37-896c-4c80-8f94-9e046453927c@googlegroups.com> <447dd1c6-1bb2-4276-a109-78d7a067b442@d8g2000pbe.googlegroups.com> <2e92b4c7-31be-40d2-a906-ab19f3630dfa@googlegroups.com> <mailman.3627.1371742717.3114.python-list@python.org> <baf4de3c-e4ff-42c0-8d65-2f6cf825735c@googlegroups.com> <51c477dd$0$29999$c3e8da3$5496439d@news.astraweb.com> <565a1c8f-6fd9-4bab-9834-076eaea527f8@googlegroups.com> <kq23at$i39$1@dont-email.me> <7e1ed740-df18-4978-b11d-8ca9c4b5bd04@googlegroups.com>
In-Reply-To: <7e1ed740-df18-4978-b11d-8ca9c4b5bd04@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: python-list@python.org
Newsgroups: comp.lang.python
Message-ID: <mailman.3667.1371842756.3114.python-list@python.org>
Lines: 88
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:48878

On 21/06/2013 19:26, Rick Johnson wrote:
> On Friday, June 21, 2013 12:47:56 PM UTC-5, Rotwang wrote:
>> It isn't clear to me from your posts what exactly you're
>> proposing as an alternative to the way Python's default
>> argument binding works. In your version of Python, what
>> exactly would happen when I passed a mutable argument as a
>> default value in a def statement? E.g. this:
>>
>>  >>> a = [1, 2, 3]
>>  >>> a.append(a)
>>  >>> b = object()
>>  >>> def f(x = [None, b, [a, [4]]]):
>> ...     pass # do something
>>
>> What would you like to see the interpreter do in this case?
>
> Ignoring that this is a completely contrived example that has
> no use in the real world, here are one of three methods by
> which i can handle this:
>
> ============================================================
>   The Benevolent Approach:
> ============================================================
> I could cast a "virtual net" over my poor lemmings before
> they jump off the cliff by throwing an exception:
>
>    Traceback (most recent screw-up last):
>     Line BLAH in SCRIPT
>      def f(x = [None, b, [a, [4]]]):
>    ArgumentError: No mutable default arguments allowed!
>
What about this:

     def f(x=Foo()):
         pass # do something

Should it raise an exception? Only if a Foo instance is mutable? How do
you know whether such an instance is mutable?

> ============================================================
>   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.
>
> ============================================================
>   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!
>
How does the "Apathetic Approach" differ from the "Malevolent Approach"?

> ============================================================
>   Conclusion:
> ============================================================
> As you can probably guess the malevolent approach has some
> nice fringe benefits.
>
> You know, out of all these post, not one of you guys has
> presented a valid use-case that will give validity to the
> existence of this PyWart -- at least not one that CANNOT be
> reproduced by using my fine examples. All you can muster is
> some weak argument about protecting the lemmings.
>
>   Is anyone up the challenge?
>   Does anyone here have any real chops?
>
> PS: I won't be holding my breath.
>
Speaking of which, on 11 January 2013, in the thread "PyWart: Import
resolution order", you were asked:

"""Got any demonstrable code for Python 4000 yet?"""

and you said:

"""I am working on it. Stay tuned. Rick is going to rock your little 
programming world /very/ soon."""

How soon is "/very/ soon" (clearly longer than 5 months), and how did
you fix this "PyWart"?