4 ms·

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

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

wlpu 5y ago
It's easy to do immutability in python, just use NamedTuple for classes and tuple instead of list
- macintux 5y ago
  I’ll research those, thanks. Any suggestions for OSS projects that do so today?
  - gravypod 5y ago
    This is a good talk that demos NamedTuple: https://www.youtube.com/watch?v=wf-BqAjZb8M https://www.youtube.com/watch?v=wf-BqAjZb8M
- japanuspus 5y ago
  ...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.
- joshuamorton 5y ago
  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.
- rurp 5y ago
  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.
- shabbyrobe 5y ago
  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/
- dexterous 5y ago
  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.
CodeMage 5y ago
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 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?
- macintux 5y ago
  I just mean it in the sense of functions without side effects on data in the program (I’m not fussed about I/O).
  - naiwenwt 5y ago
    In this particular case do you just mean pure functions then?
    - macintux 5y ago
      Sure. I’ll be honest, the distinctions are challenging to me.
- akiselev 5y ago
  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.
ketozhang 5y ago
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.
- travisjungroth 5y ago
  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.
- dexterous 5y ago
  > 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?

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

wlpu 5y ago

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

macintux 5y ago
I’ll research those, thanks. Any suggestions for OSS projects that do so today?
- gravypod 5y ago
  This is a good talk that demos NamedTuple: https://www.youtube.com/watch?v=wf-BqAjZb8M https://www.youtube.com/watch?v=wf-BqAjZb8M
japanuspus 5y ago
...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.
joshuamorton 5y ago
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.
rurp 5y ago
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.
shabbyrobe 5y ago
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/
dexterous 5y ago
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.

CodeMage 5y ago

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

macintux 5y ago
I just mean it in the sense of functions without side effects on data in the program (I’m not fussed about I/O).
- naiwenwt 5y ago
  In this particular case do you just mean pure functions then?
  - macintux 5y ago
    Sure. I’ll be honest, the distinctions are challenging to me.
akiselev 5y ago
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.

ketozhang 5y ago

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.

travisjungroth 5y ago
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.
dexterous 5y ago
> 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?