[erlang-questions] More a comment that a question
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
On Fri, Jun 8, 2012 at 1:21 PM, Bob Ippolito <bob@REDACTED> wrote:
> On Fri, Jun 8, 2012 at 9:34 AM, Paul Barry <paul.james.barry@REDACTED>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 :
> 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.
>  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).
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions