Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Default Value

Reply
Thread Tools

Default Value

 
 
Rick Johnson
Guest
Posts: n/a
 
      06-21-2013
On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
> Okay, you're trolling. Time for another month in the kill-file.
> *plonk*


That's so typical of you. You start losing an argument, and
when you have no remaining counter arguments, you resort to
name calling. Why am i not surprised? You wanna see some
trolling?

Is this all you can conjure Steven "Sauron" D'Aprano?

.... A FEW MINDLESS ORCS?

I have defeated your orcs, and your cave trolls. I have
defeated you in my darkest hour in the keep. I have thrown
out that despot from the white city, i have even slain your
Nazgul. Heck, my little sister killed your witch king.

....AND STILL YOU THINK YOU CAN DEFEAT ME!

And now, here i stand, at the foot of the mountain of doom,
with the ring of *POWER* in my hand, and i shall cast it
into the fires from whence it came!

....WHO WILL STOP ME?

All you have remaining is your beloved "gollom van rossum"
and he has already defeated himself with his blind devotion
to this despicable ring. A ring that represents illogical
and inconsistent design philosophies. A philosophy that he
himself cannot defend.

Free my people from this plague of darkness, and cast light
on these atrocities so that the sun may bleach this language
and this community clean, and maybe we'll let you visit the
shire.

....MAYBE!

 
Reply With Quote
 
 
 
 
Neil Cerutti
Guest
Posts: n/a
 
      06-21-2013
On 2013-06-21, Chris Angelico <(E-Mail Removed)> wrote:
> On Sat, Jun 22, 2013 at 4:26 AM, Rick Johnson
><(E-Mail Removed)> wrote:
>> 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!

>
> So tell me, oh Great and Powerful Wizard of Rick, how is the
> interpreter supposed to know which defaults are mutable? I
> mean, it's obviously some intrinsic property of the object.
> Somehow one thing is clearly immutable, another thing clearly
> isn't. Will there be a PyObject_IsImmutable() API?
>
> Oh! I know. Function argument defaults will now be restricted
> to int/float/tuple. That would do it, right? Nobody would be
> bothered by little restrictions like that, would they.


I've been around here long enough to have even participated in
one of these discussions before.

Rick, it's not a wart, It's a gotcha.

The reason it's a gotcha is this: In order to predict what will
happen correctly, you have to have mastered three separate Python
concepts.

1. How name-binding works.
2. How argument passing works, i.e., via name-binding.
3. When default arguments are evaluated.
4. The Python object model.

OK, you have to know four things. Curses! I'll come in again.

--
Neil Cerutti
 
Reply With Quote
 
 
 
 
MRAB
Guest
Posts: n/a
 
      06-21-2013
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"?

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      06-21-2013
On Friday, June 21, 2013 2:18:27 PM UTC-5, Rick Johnson wrote:
> On Friday, June 21, 2013 1:37:13 PM UTC-5, Steven D'Aprano wrote:
>
> > Okay, you're trolling.


Steven, you wouldn't know "trolling" even if you were an honorary salad tosser at a troll face-sitting contest.

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      06-21-2013
On Friday, June 21, 2013 2:20:22 PM UTC-5, Neil Cerutti wrote:
> Rick, it's not a wart, It's a gotcha. The reason it's a
> gotcha is this: In order to predict what will happen
> correctly, you have to have mastered three separate Python
> concepts.
>
> 1. How name-binding works.
> 2. How argument passing works, i.e., via name-binding.
> 3. When default arguments are evaluated.
> 4. The Python object model.


I understand all these concepts in a Python context quite
well, but understanding a PyWart is no validation for it's
continued existence.

You probably understand the common cold quite well. If you
do you'll wash your hands before eating, and avoid exposure
to sick people.

THAT'S CALLED A WORKAROUND!

But disease is not yet fully under human control, we are
forced to used the workaround. Whereas, languages are. So
designing a language poorly and then getting upset because
people don't praise your clunky work-around is ludicrous.

Psst: THE PROBLEM IS SELF-INDUCED!

Mankind, the only creature dumb enough to self-induce his
own hardships -- somewhere a higher intelligence must be
laughing... or crying, who knows. *sigh*
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      06-21-2013
On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
> On 21/06/2013 19:26, Rick Johnson wrote:
> > ================================================== ==========
> > 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"?


In the apathetic approach i allow the programmer to be the
sole proprietor of his own misfortunes. He lives by the
sword, and thus, he can die by the sword.

Alternatively the malevolent approach injects misfortunes
for the programmer on the behalf of esoteric rules. In this
case he will live by sword, and he could die by the sword,
or he could be unexpectedly blown to pieces by a supersonic
Howitzer shell.

It's an Explicit death versus an Implicit death; and Explicit
should ALWAYS win!

The only way to strike a reasonable balance between the
explicit death and implicit death is to throw up a warning:

"INCOMING!!!!"

Which in Python would be the "MutableArgumentWarning".

*school-bell*
 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      06-21-2013
On 21/06/2013 21:44, Rick Johnson wrote:
> On Friday, June 21, 2013 2:25:49 PM UTC-5, MRAB wrote:
>> On 21/06/2013 19:26, Rick Johnson wrote:
>> > ================================================== ==========
>> > 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"?

>
> In the apathetic approach i allow the programmer to be the
> sole proprietor of his own misfortunes. He lives by the
> sword, and thus, he can die by the sword.
>
> Alternatively the malevolent approach injects misfortunes
> for the programmer on the behalf of esoteric rules. In this
> case he will live by sword, and he could die by the sword,
> or he could be unexpectedly blown to pieces by a supersonic
> Howitzer shell.
>
> It's an Explicit death versus an Implicit death; and Explicit
> should ALWAYS win!
>
> The only way to strike a reasonable balance between the
> explicit death and implicit death is to throw up a warning:
>
> "INCOMING!!!!"
>
> 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.

 
Reply With Quote
 
Rotwang
Guest
Posts: n/a
 
      06-21-2013
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:


I didn't ask what alternative methods of handling default argument
binding exist (I can think of several, but none of them strikes me as
preferable to how Python currently does it). I asked what would happen
in /your/ version of Python. Which of the alternatives that you present
would have been implemented, if you had designed the language?


> ================================================== ==========
> 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!


So how does the interpreter know whether an arbitrary object passed as a
default value is mutable or not?

Not that it really matters. Elsewhere in this thread you wrote:

> Let's imagine for a second if Python allowed mutable keys in
> a dictionary,


which it does

> 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!


Now, I don't really believe that you think that the user shouldn't be
protected from doing one idiotic thing with mutable dict keys but should
be protected from doing another idiotic thing with mutable default
arguments, especially as you've already been given a use case for the
latter. So I assume that The Benevolent Approach is not the approach you
would have gone for if you had designed the language, right? If so then
let's ignore it.


> ================================================== ==========
> 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.


It seems to me that this is exactly what currently happens.


> ================================================== ==========
> 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!


My question was about how you think the language should work, not about
what your buddies should or shouldn't enjoy. In terms of how a language
actually works, is there any difference between The Malevolent Approach
and The Apathetic Approach? And is there any difference between either
of them and what Python currently does?


> ================================================== ==========
> 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.


Of course using a mutable default as a cache can be reproduced by other
means, as can another common use case that I don't think anyone's
mentioned yet (defining functions parametrised by variables whose values
aren't known until runtime). That's hardly an argument against it - you
might as well argue that Python shouldn't have decorators, or that it
shouldn't have for loops because their behaviour can be reproduced with
while loops.

But this is beside the point anyway, until you present an alternative to
Python's current behaviour. If you do so then we can start debating the
relative merits of the two approaches.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      06-21-2013
On Friday, June 21, 2013 5:49:51 PM UTC-5, MRAB wrote:
> I notice that you've omitted any mention of how you'd know that the
> argument was mutable.


My argument has always been that mutables should not be
passed into subroutines as default arguments because bad
things can happen. And Python's excuse of saving the poor
dummies is no excuse.

It does not matter if we are passing the arguments into the
current implementation of "python functions which maintain
state of default mutables arguments between successive
calls" or in a more desirable system of truly "stateless
subroutines".

I also believe that a programmer should not be prevented
from passing mutable default arguments, but if he does, I'm
not going to provide any sort of protection -- other than
possibly throwing up a warning message.

Now, YOU, and everyone else, cannot destroy the main points
of my argument because the points are in fact rock solid,
however, what you will do is to focus in one small detail,
one little tiny (perceived) weakness in the armor, and you
will proceed to destroy that small detail (in this case how
i will determine mutability), and hope that the destruction
of this insignificant detail will start a chain-reaction
that will propagate out and bring down my entire position.

So you want me to tell you how to query the mutability of an
object... Ha Ha Ha! Sorry, but that's not going to happen!

Why should i help the developers of this language. What have
they done for me? Hmm, let's see. They called me names.
Trolled up my posts. Written me off. Refused to answer my
questions. Been absolutely rude. etc, etc... Banned me from
lists i've never posted on and then proclaim the list is
free and open to all... BS!

WOULD YOU OFFER ASSISTANCE TO PEOPLE THAT HAVE TREATED YOU THIS WAY?

And let's just be honest. You don't want my assistance. You
just want me to fumble the ball. Then you can use that
fumble as an excuse to write me off. Nice try!

You want to gain my respect? Then start engaging in honest
debates. Start admitting that yes, somethings about Python
are not only undesirable, they're just plain wrong.

Stop calling me a troll when i am not. And not just me, stop
calling other people trolls too! Stop using the personal
attacks and straw man arguments.

Finally, get the core devs to realize that this list matters
and they need to participate (including you know who!)

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-22-2013
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.



--
Steven
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What value should be passed to make a function use the default argument value? LaundroMat Python 50 10-14-2006 05:11 AM
Default Mozilla isn't default! Help! M. FERRANTE Firefox 1 07-27-2005 09:07 AM
Using default a empty dictionary as a default value C Gillespie Python 3 03-22-2005 12:22 PM
Easy way to output a default value if <xsl:value-of/> selection comes back empty? Michael Ahlers XML 1 07-12-2004 05:17 PM
automatic default route propagation into RIP: default metric Ben Low Cisco 2 12-28-2003 03:57 AM



Advertisments