Hacker News Reader

Comment by macintux | Hacker News Reader

> Use immutability by default, even in languages that make that harder than it should be

That and referential transparency are huge wins. It is a shame languages like Python make it such a challenge.

Immutability isn't so difficult to do with Python language itself for any object. The push back is culture and practice of "we are all adults here" and that influences the language to make it forcing immutability awkward.

For example, let's assign a constant variable to a sequence; should you do use list or tuple (FOO = [1,2,3] or FOO = (1,2,3) )? It doesn't matter, the constant capitalization discourages you to mutate it.

I don’t want constants. I want immutability. The problem isn’t someone reassigning FOO. It’s them changing the data that FOO represents. So I’d love to just use Python and pass around tuples, strings, frozensets and a homemade frozendict, but the performance is terrible. Any change means a full copy of the whole data structure.

> The push back is culture and practice of "we are all adults here" and that influences the language

It's strange that a general idea expressing (assuming?) overarching maturity has led to quite so many petulant arguments, wouldn't you say @ketozhang?

This was the first time I've encountered the mention of "referential transparency", so I looked it up and went down a deep rabbit hole. It seems that it's normally used to describe the property of not having side effects, however, I also found this long explanation on Stack Overflow: https://stackoverflow.com/a/9859966/58099

So now I'm more confused than when I initially read your comment. Do you mean "referential transparency" as in "expressions without side effects" or do you mean it in some other way that I don't understand yet?

I just mean it in the sense of functions without side effects on data in the program (I’m not fussed about I/O).

In this particular case do you just mean pure functions then?

Sure. I’ll be honest, the distinctions are challenging to me.

It's more subtle than than "no side effects". Take Python prior to version 3, for example, which made possible the most egregious violation of referential transparency I've ever seen: `True, False = False, True`

Python code (pre-v3) that branches cannot be referentially transparent by definition because runtime context (the state of True/False bindings) is a hidden input in every boolean expression. You could have millions of lines of side effect free code and it will break completely if that one statement is run before the rest of the code.

Programmers depend on the referential transparency of keywords like "true", "false", "for", etc whether they're writing pure functional code or imperative spaghetti messes.

It's easy to do immutability in python, just use NamedTuple for classes and tuple instead of list

I’ll research those, thanks. Any suggestions for OSS projects that do so today?

This is a good talk that demos NamedTuple: https://www.youtube.com/watch?v=wf-BqAjZb8M

...or `dataclass(frozen=True)` if you need the ergonomics.

For non-primitive members, `frozenset` is in the standard library, but frozen dictionaries are unfortunately lacking.

Please don't do this, there are far better approaches. Use dataclasses/attrs that are frozen for immutable record types.

(Specifically avoid namedtuples unless you're hoisting a tuple to a real record. Record types also being a weird union with a tuple is...oft confusing)

For immutable basic data types, adopt type annotations and prefer to use sequence/iterable and mapping to direct didn't/list types. These provide statically verifiable immutability and also allow begin to encourage useful async-friendly patterns.

I second this. My current job is the first place I've worked where the convention is to use NamedTuples for most things I've seen dicts used for on past projects and I quite like the pattern. It both makes the code more readable and avoids a number of subtle bugs that can crop up.

Since PEP 591 [1], if using mypy with Python 3.8+ or the typing_extensions module, you can also take advantage of typing.Final, which lets you statically verify something isn't changed. The catch is that it isn't enforced at runtime.

  [1]: https://www.python.org/dev/peps/pep-0591/

Sure, we'll do all that. In the mean time, could you please get started on getting the _rest_ of the community to adopt that as a well established idiom and then also have them initiate efforts to adapt popular libraries/frameworks so that they implement the adopted idioms?

Would Thursday be a good time to checkpoint on this?

Thank you so much.

Reply on news.ycombinator.com