[erlang-questions] More a comment that a question

[Adam Rutkowski]

On Jun 8, 2012, at 7:37 PM, Eric Moritz wrote:

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

I let my Python code crash and I always regret it.
Not to mention trivial indecisions like 'how should I deal with this without pattern matching?'.

Thanks Erlang!

> 
> 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 [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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

--
AR