Jeff Knupp: Understanding Python's Execution Model

[Aditya Athalye]

I'm really liking this recent blog post by @JeffKnupp. Thought it will be
interesting for others too... Definitely one for the (my) bookmarks:

"Drastically Improve Your Python: Understanding Python's Execution Model"
http://www.jeffknupp.com/blog/2013/02/14/drastically-improve-your-python-und
erstanding-pythons-execution-model/

Best,
Aditya.

[Dhananjay Nene]

Quote: "Instead of variables (in the classic sense), Python has names and bindings."

What?? Instead of talking about call by value or call by reference semantics (or suggesting java & python essentially pass a copy of a reference to but not a deep copy of the value), the post goes into a completely strange conversation called names vs. bindings. 

In general has some good explanation of some of the aspects of python but the wording imo was a bit flippant and hence potentially confusing.

Another place where it got a bit confusing was in suggesting different types of objects mutable and immutable. AFAIK python has zero support for immutable objects at a language level (one of my top 5 peeves with the lang). The only way an object becomes immutable is by the author not introducing in mutating methods. Or if it is an instance of a built in class implemented at a C level, which is why it is not possible to set attributes of an instance of "object". Just creating a class inheriting from object does not have that limitation.

All I would suggest is read with care.

[Dhananjay Nene]

On Fri, Feb 22, 2013 at 2:01 PM, Dhananjay Nene <dhananj...@gmail.com> wrote:

On Thu, Feb 21, 2013 at 10:24 PM, Aditya Athalye <aditya....@gmail.com> wrote:

I'm really liking this recent blog post by @JeffKnupp. Thought it will be
interesting for others too... Definitely one for the (my) bookmarks:

"Drastically Improve Your Python: Understanding Python's Execution Model"
http://www.jeffknupp.com/blog/2013/02/14/drastically-improve-your-python-und
erstanding-pythons-execution-model/

The only way an object becomes immutable is by the author not introducing in mutating methods.

Even that is questionable, since it should be possible to change the attributes / methods of the object / class by doing setattr. Once again showing the language has no support for immutable objects (something that the article seems to otherwise suggest so).

[Noufal Ibrahim]

Dhananjay Nene <dhananj...@gmail.com> writes:


[...]

> Another place where it got a bit confusing was in suggesting different
> types of objects mutable and immutable. AFAIK python has zero support for
> immutable objects at a language level (one of my top 5 peeves with the
> lang).

I presume you're talking about user defined objects? Strings in Python
are immutable. Are they not?

[...]


--
Cordially,
Noufal
http://nibrahim.net.in

[Dhananjay Nene]

Forgot to do a reply-all

On Fri, Feb 22, 2013 at 2:37 PM, Dhananjay Nene <dhananj...@gmail.com> wrote:

On Fri, Feb 22, 2013 at 2:23 PM, Noufal Ibrahim <nou...@gmail.com> wrote:

Dhananjay Nene <dhananj...@gmail.com> writes:


[...]

> Another place where it got a bit confusing was in suggesting different
> types of objects mutable and immutable. AFAIK python has zero support for
> immutable objects at a language level (one of my top 5 peeves with the
> lang).

I presume you're talking about user defined objects? Strings in Python
are immutable. Are they not?

I was talking of "at a language level". The implementation of strings makes it immutable because it has no mutating methods and also because it is kind of hard to monkeypatch it as well. There are unlikely any declarations in the string class (haven't seen it myself) which tell the language runtime please make my instances immutable. For a language truly supporting immutability I imagine there should be some support for declaring an instance as immutable (alternatively having immutable instances by default and thus declaring some instances as mutable or not at all).

User defined objects also do not become immutable by just offering non mutating methods. They also need to capture setattr / getattr to ensure someone doesn't monkeypatch them away.

But thats like having a personal security system to thwart any intruders as opposed to an environment of low crime :)

 

--
----------------------------------------------------------------------------------------------------------------------------------
http://blog.dhananjaynene.com twitter: @dnene google plus: http://gplus.to/dhananjaynene

[Noufal Ibrahim]

Dhananjay Nene <dhananj...@gmail.com> writes:


[...]

>> I was talking of "at a language level". The implementation of strings
>> makes it immutable because it has no mutating methods and also because it
>> is kind of hard to monkeypatch it as well. There are unlikely any
>> declarations in the string class (haven't seen it myself) which tell the
>> language runtime please make my instances immutable. For a language truly
>> supporting immutability I imagine there should be some support for
>> declaring an instance as immutable (alternatively having immutable
>> instances by default and thus declaring some instances as mutable or not at
>> all).
>>
>> User defined objects also do not become immutable by just offering non
>> mutating methods. They also need to capture setattr / getattr to ensure
>> someone doesn't monkeypatch them away.

Good point.

[Dhananjay Nene]

On Fri, Feb 22, 2013 at 3:11 PM, steve <st...@lonetwin.net> wrote:

I'm not sure how you can choose to define immutability in your terms and then claim that the language doesn't support immutability. Yeah, the language doesn't offer 'implicit' facilities to declare an object as immutable, but that doesn't mean, immutability doesn't exist.

The language does not offer "explicit" facilities to declare an object as immutable (eg. const in C++)

To quote the post: "It turns out Python has two flavors of objects: mutable and immutable."

What it seems to imply is not true. I cannot create a class and then tell the language runtime it is immutable. I cannot create an instance and pass it to another function and say I expect it to be not modified. 

When I hear a language supports immutability I expect some explicit support in the language to support immutability. I would love to be able to define a class like the tuple, and then tell the language it should not be modified. A hypothetical version of python that in my mind supported immutability would automatically reject any setattr calls on i

I think you should explore if you do find any difference in "existence of mutable and  immutable objects" and "a language having two flavours of objects mutable and immutable". To me "a language having two flavours of objects suggests someone being able to tell the language I want instances of a class or a particular instance or a particular reference being passed to a function to be immutable. Otherwise in my mind it the language does not support immutability (although it merely allows its existence). Is that redefinition of immutability on my terms ? If you still think so, I have made my case to the extent I could, and you could conclude with the judgement you find appropriate.

[dexterous]

On Friday, February 22, 2013 2:01:32 PM UTC+5:30, Dhananjay Nene wrote:

Quote: "Instead of variables (in the classic sense), Python has names and bindings."

What?? Instead of talking about call by value or call by reference semantics (or suggesting java & python essentially pass a copy of a reference to but not a deep copy of the value), the post goes into a completely strange conversation called names vs. bindings. 

AFAIK, names and binding are a part of the standard terminology in python => https://www.google.co.in/search?q=site%3Apython.org+name+binding

Don't understand why you find it strange. Personally, I've read of them in several concepts and feel that understanding those concepts help in understanding the import mechanism.

- d

[Noufal Ibrahim]

Dhananjay Nene <dhananj...@gmail.com> writes:

> On Fri, Feb 22, 2013 at 3:11 PM, steve <st...@lonetwin.net> wrote:
>
>>
>> I'm not sure how you can choose to define immutability in your terms and
>> then claim that the language doesn't support immutability. Yeah, the
>> language doesn't offer 'implicit' facilities to declare an object as
>> immutable, but that doesn't mean, immutability doesn't exist.
>
>
> The language does not offer "explicit" facilities to declare an object as
> immutable (eg. const in C++)

[...]

In one of the projects that I did, I was the only Python guy on the
team. The rest were C system programmers. They did some Python C module
and presented me with a function that I could pass a python string
to. The function would return 1 or 0 implying success or failure (no
exceptions) and the result? Well, the C module would actually rewrite
the string passed to it and so my input string would change.

I had a discussion with him on how strings are immutable in Python and
he "proved" to me how that's not true.

[Dhananjay Nene]

That was a typo - he was talking about variables vs. bindings. But did not issue a correction since I thought anyone would obviously figure out that the post referred to a dichotomy between variables and (names and bindings).

In any case my issue was specifically attempting to discuss the matters without getting into value / reference semantics - which offers a clearer way of describing what the author really wanted to describe.

[Dhananjay Nene]

And just to clarify - "without getting into the """semantics of values and references""" eg. as used in call by value / call by reference" 

[dexterous]

IMHO, names and bindings is an alternate way of looking at superset of ideas that also encompasses call by value/reference; and explains it pretty well. YMMV

- d 

[Dhananjay Nene]

I have to get off this discussion. But you seem to completely ignore the original quote which I pointed out to  "Instead of variables (in the classic sense), Python has names and bindings." I of course also need to figure out how names and bindings encompass call by value because that is something thats escaping me at the moment.

[yati sagade]

>That was a typo - he was talking about variables vs. bindings. But did not issue a correction since I thought anyone would obviously figure out
> that the post referred to a dichotomy between variables and (names and bindings).

What was a typo? I don't see anything in the article that conveys anything wrong about names or bindings.

--
Yati Sagade

Software Engineer at mquotient

Twitter: @yati_itay | Github: yati-sagade

Organizing member of TEDx EasternMetropolitanBypass
http://www.ted.com/tedx/events/4933
https://www.facebook.com/pages/TEDx-EasternMetropolitanBypass/337763226244869

[Dhananjay Nene]

On Fri, Feb 22, 2013 at 4:04 PM, yati sagade <yati....@gmail.com> wrote:

>That was a typo - he was talking about variables vs. bindings. But did not issue a correction since I thought anyone would obviously figure out
> that the post referred to a dichotomy between variables and (names and bindings).

What was a typo? I don't see anything in the article that conveys anything wrong about names or bindings.

Typo in what I had stated "names vs. bindings". The article in essence was talking about "variables vs. (names/bindings)" 

--
Yati Sagade

Software Engineer at mquotient

Twitter: @yati_itay | Github: yati-sagade

Organizing member of TEDx EasternMetropolitanBypass
http://www.ted.com/tedx/events/4933
https://www.facebook.com/pages/TEDx-EasternMetropolitanBypass/337763226244869

--
You received this message because you are subscribed to the Google Groups "Python Pune" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pythonpune+...@googlegroups.com.
To post to this group, send email to pytho...@googlegroups.com.
Visit this group at http://groups.google.com/group/pythonpune?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dhananjay Nene]

On Fri, Feb 22, 2013 at 3:57 PM, steve <st...@lonetwin.net> wrote:

On Friday 22 February 2013 03:24 PM, Dhananjay Nene wrote:

On Fri, Feb 22, 2013 at 3:11 PM, steve <st...@lonetwin.net

<mailto:st...@lonetwin.net>> wrote:


    I'm not sure how you can choose to define immutability in your terms and
    then claim that the language doesn't support immutability. Yeah, the
    language doesn't offer 'implicit' facilities to declare an object as
    immutable, but that doesn't mean, immutability doesn't exist.


The language does not offer "explicit" facilities to declare an object as
immutable (eg. const in C++)

To quote the post: "It turns out Python has two flavors of objects:
|mutable| and |immutable|."

What it seems to imply is not true. I cannot create a class and then tell the
language runtime it is immutable. I cannot create an instance and pass it to
another function and say I expect it to be not modified.

When I hear a language supports immutability I expect some explicit support in
the language to support immutability. I would love to be able to define a class
like the tuple, and then tell the language it should not be modified. A
hypothetical version of python that in my mind supported immutability would
automatically reject any setattr calls on i

Look at the code in my previous post or the one below

I think you should explore if you do find any difference in "existence of
mutable and  immutable objects" and "a language having two flavours of objects
mutable and immutable". To me "a language having two flavours of objects
suggests someone being able to tell the language I want instances of a class or
a particular instance or a particular reference being passed to a function to be
immutable. Otherwise in my mind it the language does not support immutability
(although it merely allows its existence). Is that redefinition of immutability
on my terms ? If you still think so, I have made my case to the extent I could,
and you could conclude with the judgement you find appropriate.

Yes, I do think it is redefinition of immutability on your terms, because here's what the python definition from the official docs:
http://docs.python.org/2/reference/datamodel.html

"""
 The value of some objects can change. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. (The value of an immutable container object that contains a reference to a mutable object can change when the latter’s value is changed; however the container is still considered immutable, because the collection of objects it contains cannot be changed. So, immutability is not strictly the same as having an unchangeable value, it is more subtle.) An object’s mutability is determined by its type; for instance, numbers, strings and tuples are immutable, while dictionaries and lists are mutable.
"""

By that definition, instances of these class are immutable:

>>> class T(tuple):
...     pass
...
 >>> t = T(range(5))
 >>> t[0] = 42
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: 'T' object does not support item assignment

>>> class Age(int):
...     pass
...
>>> a = Age(10)
>>> id(a)
140374901745352
>>> a
10
>>> a += 20
>>> id(a)
6579456
>>> class Only42(object):
...     @property
...     def value(self):
...             return 42
...
>>> o = Only42()
>>> o.value
42
>>> o.value = 10

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

AttributeError: can't set attribute
>>>

If it was immutable, how could I get away with the following redefinition?

class Only42(object):

    @property

    def value(self):

        return 42

def fortythree(self) : return 43

Only42.value = fortythree

print(Only42().value())

(I did not work on the property part of it so had to tack on an extra () at the end). Or is redefinition for methods allowed for immutable objects?

 

If you want to extend that further and say that new attributes too should not be possible, use __slots__. Not sure if you read through the code I posted in my previous reply, so here goes ...

>>> class Only42(object):
...     __slots__ = ['value']
...     @property
...     def value(self):
...         return 42
...
>>> o = Only42()
>>> o.value = 10

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

AttributeError: can't set attribute
>>> o.new_value = 20

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

AttributeError: 'Only42' object has no attribute 'new_value'
>>>

So, the point I was trying to make is 'mutable' and 'immutable' means something very specific in python. If you want your classes to behave like immutables types in python, derive from them (again, look at my code from the previous post) or use facilities like __slots__.

cheers,
- steve

[Dhananjay Nene]

This was python3.2 btw. 

[Aditya Athalye]

Holy Stack Overflow, Batman, what have I done?!

 

 

[Dhananjay Nene]

On Fri, Feb 22, 2013 at 4:22 PM, Aditya Athalye <aditya....@gmail.com> wrote:

Holy Stack Overflow, Batman, what have I done?!

 

Nothing .. its my response which has triggered off the discussion .. not your original post 

 

--
You received this message because you are subscribed to the Google Groups "Python Pune" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pythonpune+...@googlegroups.com.
To post to this group, send email to pytho...@googlegroups.com.
Visit this group at http://groups.google.com/group/pythonpune?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dhananjay Nene]

Forgot to cc to the list

On Fri, Feb 22, 2013 at 4:39 PM, Dhananjay Nene <dhananj...@gmail.com> wrote:

The original Only42 had no member attributes for the methods save the method itself. 

The correct counter assuming attribute which are bound to values should've been as follows 

class Only(object):

    def __init__(self, value) :

         self._value = value

    @property

    def value(self):

        return self._value

only42 = Only(42)

setattr(only42, "_value", 43)

print(only42.value)

The way to programmatically enforce immutability is as follows :

    def __init__(self, value) :

         self._value = value

    @property

    def value(self):

        return self._value

    def __setattr__(self,name,val) :

        raise Exception("I intend this object to have its value perpetually set to {}".format(self._value))

only42 = Only(42)

setattr(only42, "_value", 43)

print(only42.value)

The way I simulate what a language support would've done is simulated through a @immutable decorator here

def immutable (cls):

    def blocksetattr(self,name,val) :

        raise Exception("I intend this object to be immutable")

    cls.__setattr__ = blocksetattr

    return cls

@immutable

class Only(object):

    def __init__(self, value) :

         self._value = value

    @property

    def value(self):

        return self._value

only42 = Only(42)

setattr(only42, "_value", 43)

print(only42.value)

(gmail tells me you've sent me a response to my earlier reply .. but haven't seen it yet as I write and send this)

[Dhananjay Nene]

Yet again did not do a reply-all :(

On Fri, Feb 22, 2013 at 4:45 PM, Dhananjay Nene <dhananj...@gmail.com> wrote:

The original Only42 had no member attributes for the methods save the method itself. 

The correct counter assuming attribute which are bound to values should've been as follows 

I'm being picky since want to ensure my casual style of writing / typos do not get interpreted differently from what I in my mind intended)

The original   Only42 had no member attributes for the "class"/"object" save the method itself.

The correct counter in a scenario where member attribute names are bound to values which are not methods would've been 

[Dhananjay Nene]

A slightly more useful version of the immutable decorator (the earlier was indicative but crapped out in the __init__ itself)

def immutable (cls):

    def blocksetattr(self,name,val) :

        raise Exception("I intend this object to be immutable")

    oldinit = cls.__init__

    def replacement_init(*args, **kwargs) :

        oldinit(*args, **kwargs)

        cls.__setattr__ = blocksetattr

    cls.__init__ = replacement_init

    return cls

@immutable

class Only(object):

    def __init__(self, value) :

         # this will get allowed

         self._value = value

    @property

    def value(self):

        return self._value

only42 = Only(42)

# This will fail

[Dhananjay Nene]

On Fri, Feb 22, 2013 at 5:03 PM, Dhananjay Nene <dhananj...@gmail.com> wrote:

A slightly more useful version of the immutable decorator (the earlier was indicative but crapped out in the __init__ itself)

even this fails on a second object construction  .. but I hope I have conveyed by what I think what language support for immutable structures will entail. Will wonder later if there's a way to fix this too.

def immutable (cls):

    def blocksetattr(self,name,val) :

        raise Exception("I intend this object to be immutable")

    oldinit = cls.__init__

    def replacement_init(*args, **kwargs) :

        oldinit(*args, **kwargs)

        cls.__setattr__ = blocksetattr

    cls.__init__ = replacement_init

    return cls

@immutable

class Only(object):

    def __init__(self, value) :

         # this will get allowed

         self._value = value

    @property

    def value(self):

        return self._value

only42 = Only(42)

# This will fail

setattr(only42, "_value", 43)

print(only42.value)

[dexterous]

I don't know why you feel I've ignore the quote. If I'm not mistaken, your position is that the author should simply have expressed the idea in terms of call/pass by value/reference of variables instead of introducing the concepts of names and bindings, right?

But as I see it that's the author's point (and I agree), once you put together 'everything is an object' and 'names + bindings' there is essentially no call by value (where value is some primitive). It's all a matter of creating names and binding 'things' to them. So, WRT your original reply, I don't see the conversations as '[variables] vs. bindings'; I see it more on the lines of 'unlearn variables and learn names + bindings'. That's all. YMMV

Besides, I've never really found the call/pass by value/reference discussion tremendously valuable. Most people misunderstand it; and those that get it tend to shave yaks.

- d

[steve]

On Friday 22 February 2013 03:24 PM, Dhananjay Nene wrote:
>

> On Fri, Feb 22, 2013 at 3:11 PM, steve <st...@lonetwin.net
> <mailto:st...@lonetwin.net>> wrote:
>
>
> I'm not sure how you can choose to define immutability in your terms and
> then claim that the language doesn't support immutability. Yeah, the
> language doesn't offer 'implicit' facilities to declare an object as
> immutable, but that doesn't mean, immutability doesn't exist.
>
>
> The language does not offer "explicit" facilities to declare an object as
> immutable (eg. const in C++)
>
> To quote the post: "It turns out Python has two flavors of objects:
> |mutable| and |immutable|."
>
> What it seems to imply is not true. I cannot create a class and then tell the
> language runtime it is immutable. I cannot create an instance and pass it to
> another function and say I expect it to be not modified.
>
> When I hear a language supports immutability I expect some explicit support in
> the language to support immutability. I would love to be able to define a class
> like the tuple, and then tell the language it should not be modified. A
> hypothetical version of python that in my mind supported immutability would
> automatically reject any setattr calls on i
>

Look at the code in my previous post or the one below

> I think you should explore if you do find any difference in "existence of
> mutable and immutable objects" and "a language having two flavours of objects
> mutable and immutable". To me "a language having two flavours of objects
> suggests someone being able to tell the language I want instances of a class or
> a particular instance or a particular reference being passed to a function to be
> immutable. Otherwise in my mind it the language does not support immutability
> (although it merely allows its existence). Is that redefinition of immutability
> on my terms ? If you still think so, I have made my case to the extent I could,
> and you could conclude with the judgement you find appropriate.
>

Yes, I do think it is redefinition of immutability on your terms, because here's
what the python definition from the official docs:
http://docs.python.org/2/reference/datamodel.html

"""
The value of some objects can change. Objects whose value can change are said
to be mutable; objects whose value is unchangeable once they are created are
called immutable. (The value of an immutable container object that contains a

reference to a mutable object can change when the latter�s value is changed;

however the container is still considered immutable, because the collection of
objects it contains cannot be changed. So, immutability is not strictly the same

as having an unchangeable value, it is more subtle.) An object�s mutability is

[steve]

ehe, ..

>>> t = tuple(range(5))
>>> t
(0, 1, 2, 3, 4)

>>> t[0] = 42
Traceback (most recent call last):
File "<stdin>", line 1, in <module>

TypeError: 'tuple' object does not support item assignment

>>> class T(tuple):
... pass
...
>>> t = T(range(5))
>>> t[0] = 42
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'T' object does not support item assignment

>>> class IM(object):
... __slots__ = []
...
>>> im = IM()
>>> im.new_attr = 42

Traceback (most recent call last):
File "<stdin>", line 1, in <module>

AttributeError: 'IM' object has no attribute 'new_attr'

>>>

I'm not sure how you can choose to define immutability in your terms and then
claim that the language doesn't support immutability. Yeah, the language doesn't
offer 'implicit' facilities to declare an object as immutable, but that doesn't
mean, immutability doesn't exist.

cheers,
- steve

[steve]

On Friday 22 February 2013 04:11 PM, Dhananjay Nene wrote:
> [..snip...]

>
> I think you should explore if you do find any difference in "existence of
> mutable and immutable objects" and "a language having two flavours of
> objects
> mutable and immutable". To me "a language having two flavours of objects
> suggests someone being able to tell the language I want instances of a
> class or
> a particular instance or a particular reference being passed to a
> function to be
> immutable. Otherwise in my mind it the language does not support
> immutability
> (although it merely allows its existence). Is that redefinition of
> immutability
> on my terms ? If you still think so, I have made my case to the extent I
> could,
> and you could conclude with the judgement you find appropriate.
>
>
> Yes, I do think it is redefinition of immutability on your terms, because
> here's what the python definition from the official docs:

> http://docs.python.org/2/__reference/datamodel.html

...but, by doing this you've *redefined* the class ! So this is no longer the
same object. The fact that redefining the class dynamically is allowed doesn't
imply that the data model is inconsistent.

I mean, you do know, don't you, what python implies when it says strings are
immutable but allows this ?:

s = "foo"
s = s + "bar"

Isn't your code doing the same thing to the class Only42 ?

cheers,
- steve

[steve]

Hi,

...but even this fails if you employed the same logic about immutability as you
did earlier:

>>> def setme(self, name, val): self.__dict__[name] = val
...
>>> Only.__setattr__ = setme
>>> setattr(only42, "_value", 43)
>>> only42.value
43

did you assume __setattr__ be different than any other method ?

In my head at least, immutability in python is something either immutable types
have (like numbers, strings and tuples) or something that you lay down as a
contract using the facilities of the language. Breaking the contract (like
perhaps what Noufal's colleague did in 'proving' strings to be immutable)
doesn't count as valid behaviour.

If for you, immutability implies that assignment (or modification of values via
any other approach) is disallowed, no matter what, yes, python doesn't have
immutable objects, just immutable types -- which also aren't really immutable
because you can hack the C-representation. This though, afaict, is not the
python definition of immutability.

cheers,
- steve

[dexterous]

That said, a lot of the blog post does appear to be either an over-simplification or a superficial view of some of the fundamental concepts; so I do agree with your cautionary notice to **read with care**.

- d

[dexterous]

On Friday, February 22, 2013 4:22:39 PM UTC+5:30, Aditya Athalye wrote:

Holy Stack Overflow, Batman, what have I done?!

Yes Robin, what we're looking at here is

• a definitely interesting and apparently cogent post on the a set of language features;
  
• which a lot of people don't usually give too much thought to;
  
• which, generally speaking, is a valuable attribute of a language/platform as programmers usually shouldn't have to worry about these;
  
• which, however, is not always desirable as a lack of understand of said features hurts when said feature bites you in the behind;
  
• which, in this case, is not helped by the fact that the article is simply not all that good!
  

Conclusion, we must be a little more careful when evaluating explanations of inherently difficult topics. ;)

Now, to the Bat Cave! And, for posting an article that caused more debate than was necessary, you don't get to ride the BatMobile! Here's the bus fare.

- d

PS- above post to be taken in good spirits, preferably rum or a clear white wine.

[Dhananjay Nene]

Which is why I was suggesting I was simulating. There's a limit to how far I can go as a lay programmer (as opposed to one who coded the lang spec and wrote the compiler/runtime). Is also indicative of the fact that I find it very hard to define classes which can create truly immutable objects. That is a real limitation w/ python imo.

>>> def setme(self, name, val): self.__dict__[name] = val
...
>>> Only.__setattr__ = setme
>>> setattr(only42, "_value", 43)
>>> only42.value
43

did you assume __setattr__ be different than any other method ?

It is different to the extent it is the portal to mutability 

In my head at least, immutability in python is something either immutable types have (like numbers, strings and tuples) or something that you lay down as a contract using the facilities of the language. Breaking the contract (like perhaps what Noufal's colleague did in 'proving' strings to be immutable) doesn't count as valid behaviour.

 "immutability in python" becomes a strange notion if it declares to be different from "immutability in other languages" substantially. immutability means something cannot be changed. I tried to look for a language neutral definition of immutability and here's what google came up with http://www.site.uottawa.ca:4321/oose/index.html#immutable I think it helps describe the rationale for immutability well. Key aspects there are (and I quote) "An important reason for using an immutable object is that other objects can trust its content to not unexpectedly change." and "The immutability must be enforced. and There must be no loopholes that would allow 'illegal' modification of an immutable object." 

If for you, immutability implies that assignment (or modification of values via any other approach) is disallowed, no matter what, yes, python doesn't have immutable objects, just immutable types -- which also aren't really immutable because you can hack the C-representation. This though, afaict, is not the python definition of immutability.

Yes I have a notion of immutability. And I also have a notion of what it means for a language to support immutability. I think where we differ is "python definition of immutability". You treat that as a primary reference. My notion is more driven by the considerations documented in the definition I pasted earlier. 

cheers,
- steve

 
--
You received this message because you are subscribed to the Google Groups "Python Pune" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pythonpune+unsubscribe@googlegroups.com.

To post to this group, send email to pytho...@googlegroups.com.
Visit this group at http://groups.google.com/group/pythonpune?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Aditya Athalye]

From: pytho...@googlegroups.com [mailto:pytho...@googlegroups.com]
On Behalf Of dexterous
Sent: 22 February 2013 18:13
[...]

> Now, to the Bat Cave! And, for posting an article that caused
> more debate than was necessary, you don't get to ride
> the BatMobile! Here's the bus fare.

> PS- above post to be taken in good spirits, preferably rum or a clear
white wine.

[...]

Takes bus fare, feeling foo-lish.
En-route, stops at bar.
:)