«

On 2010-11-01 22:31 , Lawrence D'Oliveiro wrote:
> In message<>, Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>
>>> And how does Python know whether some arbitrary default object is mutable
>>> or not?
>>
>> It doesn't, that's the whole point.
>
> Of course it knows. It is the one defining the concept in the first place,
> after all.

No, the Python interpreter doesn't define the concept. The Python language
developers did. "Immutable objects" are just those without an obvious API for
modifying them. With various trickeries, I can mutate any immutable object. The
Python interpreter doesn't know what's an "obvious API" and what isn't. It's a
reasonably vague concept that doesn't have an algorithmic formulation.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

In message <mailman.475.1288670833.2218.python->, Robert Kern
wrote:

> On 2010-11-01 22:31 , Lawrence D'Oliveiro wrote:
>
>> In message<>, Gregory Ewing wrote:
>>
>>> Steven D'Aprano wrote:
>>>
>>>> And how does Python know whether some arbitrary default object is
>>>> mutable or not?
>>>
>>> It doesn't, that's the whole point.
>>
>> Of course it knows. It is the one defining the concept in the first
>> place, after all.
>
> No, the Python interpreter doesn't define the concept. The Python language
> developers did.

The Python language developers said “let there be light�, and the Python
interpreter gave forth light. So which one defines the concept of “light�?

> "Immutable objects" are just those without an obvious API for modifying
> them.

They are ones with NO legal language constructs for modifying them. Hint: if
a selector of some part of such an object were to occur on the LHS of an
assignment, and that would raise an error, then the object is immutable. The
interpreter already knows all this.

> With various trickeries, I can mutate any immutable object.

None within the Python language itself. Which is what we’re talking about
here: a language construct which is probably one of the top 3 sources of
grief to Python newbies. And not-so-newbies.

On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano
<> wrote:
> On Thu, 21 Oct 2010 19:53:53 -0700, John Nagle wrote:
>>> This is a common newbie stumbling-block: Don't use lists (or anything
>>> mutable) as default argument values
>>
>> Â* Â* Â*That really should be an error.
>
> No it shouldn't. Punishing everybody for a newbie mistake that nobody
> makes twice would be the error.
>
> Default mutable arguments have their place

But it's a rather obscure one where it is almost never strictly
necessary to venture.

Cheers,
Chris

In message <mailman.481.1288683620.2218.python->, Chris
Rebert wrote:

> On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano
> <> wrote:
>>
>> Default mutable arguments have their place
>
> But it's a rather obscure one where it is almost never strictly
> necessary to venture.

Mediocre programmers with a hankering towards cleverness latch onto it as an
ingenious way of maintaing persistent context in-between calls to a
function, completely overlooking the fact that Python offers much more
straightforward, comprehensible, flexible, and above all maintainable ways
of doing that sort of thing.

On Tue, 02 Nov 2010 22:06:40 +1300, Lawrence D'Oliveiro wrote:

> In message <mailman.481.1288683620.2218.python->, Chris
> Rebert wrote:
>
>> On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano
>> <> wrote:
>>>
>>> Default mutable arguments have their place
>>
>> But it's a rather obscure one where it is almost never strictly
>> necessary to venture.
>
> Mediocre programmers with a hankering towards cleverness latch onto it
> as an ingenious way of maintaing persistent context in-between calls to
> a function, completely overlooking the fact that Python offers much more
> straightforward, comprehensible, flexible, and above all maintainable
> ways of doing that sort of thing.

Perhaps.

Or maybe it's the mediocre programmers who find mutable defaults
confusing, incomprehensible and unmaintainable.

Certainly it's the mediocre programmers who seem to be incapable of
understanding that Python has no way of telling whether arbitrary objects
are mutable or not.

def foo(x, y=list()):
pass

Is y a mutable default or not?

For the benefit of any mediocre programmers out there, be careful before
you answer. This *is* a trick question.


--
Steven

On Tue, 02 Nov 2010 20:12:49 +1300, Lawrence D'Oliveiro wrote about
mutable defaults:

> Which is what we’re talking about
> here: a language construct which is probably one of the top 3 sources of
> grief to Python newbies. And not-so-newbies.


I call bullshit. Maybe you should spend some time on the
mailing list for a while to see what the common problems newbies actually
have. Mutable defaults are *way* down the list.

In any case, Python isn't written solely for newbies. Most people will
make this mistake once, or twice if they're particularly slow learning.
If newbies have a problem with mutable defaults, oh well, they'll learn,
or they'll give up and go back to griefing their friends on Facebook.
Either way, problem solved.


--
Steven

On Tue, 02 Nov 2010 00:40:17 -0700, Chris Rebert wrote:

> On Fri, Oct 22, 2010 at 12:36 AM, Steven D'Aprano
> <> wrote:
>> On Thu, 21 Oct 2010 19:53:53 -0700, John Nagle wrote:
>>>> This is a common newbie stumbling-block: Don't use lists (or anything
>>>> mutable) as default argument values
>>>
>>> Â* Â* Â*That really should be an error.
>>
>> No it shouldn't. Punishing everybody for a newbie mistake that nobody
>> makes twice would be the error.
>>
>> Default mutable arguments have their place
>
> But it's a rather obscure one where it is almost never strictly
> necessary to venture.

Very few language features are *strictly* necessary. I mean, all you
really need is the ability to set the current memory location, a way to
read and write to it, and a way to branch. Everything else is just gravy.

Not that I'm suggesting we should all use Turing machines, but there are
many things which aren't strictly necessary but are nice to have.

In any case, this discussion is pointless. There is code out there that
uses this feature, whether you (generic you) like it or not, and changing
the behaviour *can't* happen until the moratorium ends. Even if there was
consensus to make this change -- and there won't be -- it almost
certainly won't happen before Python 4000.

Even if it did happen, adding extra type-checks to every def statement
with a default value, or adding extra complexity to the parser, won't and
can't catch every mutable default because there is no way of telling
whether an arbitrary object is mutable. It will just slow down the
language for bugger-all benefit.


--
Steven

On 11/2/2010 3:12 AM, Lawrence D'Oliveiro wrote:

>> "Immutable objects" are just those without an obvious API for modifying
>> them.

After initial creation /

> They are ones with NO legal language constructs for modifying them.

Suppose I write an nasty C extension that mutates tuples. What then
would be illegal about

import tuple_mutator
t = (1,2)
tuple_mutator.inc(t)
t
# (2,3)

> Hint: if
> a selector of some part of such an object were to occur on the LHS of an
> assignment, and that would raise an error, then the object is immutable.

I am not sure what you are saying here, and how it applies to

>>> lt = [(0,)]
>>> lt[0][0] = 1
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
lt[0][0] = 1
TypeError: 'tuple' object does not support item assignment
>>> tl = ([0],)
>>> tl[0][0] = 1
>>> tl
([1],)


--
Terry Jan Reedy

On 11/2/10 2:12 AM, Lawrence D'Oliveiro wrote:
> In message<mailman.475.1288670833.2218.python->, Robert Kern
> wrote:
>
>> On 2010-11-01 22:31 , Lawrence D'Oliveiro wrote:
>>
>>> In message<>, Gregory Ewing wrote:
>>>
>>>> Steven D'Aprano wrote:
>>>>
>>>>> And how does Python know whether some arbitrary default object is
>>>>> mutable or not?
>>>>
>>>> It doesn't, that's the whole point.
>>>
>>> Of course it knows. It is the one defining the concept in the first
>>> place, after all.
>>
>> No, the Python interpreter doesn't define the concept. The Python language
>> developers did.
>
> The Python language developers said “let there be light�, and the Python
> interpreter gave forth light. So which one defines the concept of “light�?

I'm sorry, but that's not even a meaningful reply. They said no such thing and
the interpreter does no such thing. Let's talk about things the developers did
say and the things the interpreter does do, shall we?

The Python language developers defined the concept of mutable objects. However,
they defined it in human terms, not algorithmic ones. They did not imbue the
interpreter with a way of determining immutability.

>> "Immutable objects" are just those without an obvious API for modifying
>> them.
>
> They are ones with NO legal language constructs for modifying them. Hint: if
> a selector of some part of such an object were to occur on the LHS of an
> assignment, and that would raise an error, then the object is immutable. The
> interpreter already knows all this.

Incorrect. RHS method calls can often modify objects. set.add() mutates the set
even though it does not have the usual LHS mutation methods like .__setitem__().
And even among the LHS APIs, raising an error does not determine immutability.
int.__iadd__() does not raise an error, but ints are still immutable.
list.__iadd__() does not raise an error, and lists are mutable. And even if it
were reliable, how would the interpreter know what arguments to pass?
list.__iadd__() doesn't work for any object. And why do you think that testing
mutability in such a way would be safe since attempting those would necessarily
alter the object if it is mutable?

Show me the algorithm that the interpreter can use to determine whether or not
an object is mutable. Or better, since you think the interpreter already knows
this, show me the implementation in the interpreter's source code.

>> With various trickeries, I can mutate any immutable object.
>
> None within the Python language itself. Which is what we’re talking about
> here: a language construct which is probably one of the top 3 sources of
> grief to Python newbies. And not-so-newbies.

"import ctypes" is within the Python language.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

On Nov 2, 5:59*am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> Certainly it's the mediocre programmers who seem to be incapable of
> understanding that Python has no way of telling whether arbitrary objects
> are mutable or not.
>
> def foo(x, y=list()):
> * * pass
>
> Is y a mutabledefaultor not?
>
> For the benefit of any mediocre programmers out there, be careful before
> you answer. This *is* a trick question.

I fail to see your point. You might as well argue that Python has no
way of knowing whether it should raise a TypeError in the following
example:

my_tuple = (1, 2, 3) + list(xrange(4, 7))

Dynamic typing means that these sorts of checks must be delayed until
runtime, but that doesn't make them useless or impossible.

It seems to me that there is a rather simple case to be made for
allowing mutable default arguments: instances of user-defined classes
are fundamentally mutable. Disallowing mutable default arguments
would mean disallowing instances of user-defined classes entirely.
That would be excessive and would violate Python's general rule of
staying out of the programmer's way.

Cheers,
Ian