[erlang-questions] More a comment that a question

Eric Moritz <>
Fri Jun 8 19:37:58 CEST 2012


Where the danger comes in is mutating object, lists and dicts that other
threads or functions have references to.  It is possible to have a
reference to a dict in a module or up the call stack that gets changed in
an unexpected way and things crash.  Erlang has made me a very paranoid
Python developer.

On Fri, Jun 8, 2012 at 1:21 PM, Bob Ippolito <> wrote:

> On Fri, Jun 8, 2012 at 9:34 AM, Paul Barry <>wrote:
>
>>
>> I've been coding/working with Erlang (and Chicago Boss) for a while
>> now, and I've recently had to do some work in Python.  I find myself
>> looking at some code I'm writing that looks like this:
>>
>>   html = html + "some markup"
>>
>> and getting nervous as I know this is a "naughty" that Erlang would
>> not let me away with.   If only there was a "make everything
>> immutable" switch for Python!  ;-)
>
>
> Strictly speaking, there's no mutation at all here, because str in Python
> *are* immutable. What's happening is that the variable html is rebound to
> the result. This is roughly equivalent to something like this in Erlang [1]:
>
>     HTML1 = <<HTML/binary, "some markup">>.
>
> You really wouldn't want to have to write Python in single assignment
> form, especially without tail call optimization. Python IO would benefit
> from something like Erlang's iolist, but for use cases like the above
> people tend to append to a list and then join it with the empty string, or
> use an instance of cStringIO.StringIO.
>
> [1] Some versions of CPython do have some hacks that can detect this x +=
> s where x is a string with a reference count of 1 and strategically do
> these updates in-place with over-allocation... so it's possible that it's
> not quite as bad as you think it is (amortized).
>
> -bob
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120608/2c28324a/attachment.html>


More information about the erlang-questions mailing list