(1) It doesn't make the language less efficient
(2) The new feature is coherent with the rest of the language
(3) It doesn't make learning the language harder
(4) It brings joy in my life (as f-strings do)
Then.. it's ok :-)
(1) It doesn't make the language less efficient
(2) The new feature is coherent with the rest of the language
(3) It doesn't make learning the language harder
(4) It brings joy in my life (as f-strings do)
Then.. it's ok :-)
- Tooling, code analysers, etc. have to be updated to understand the new features. Tools which are dead or "finished" may stop working.
- The possibility that someone might use a new feature can break guarantees that are relied upon by existing code. An obvious example would be adding try/catch to a language: in languages without this, a function call is guaranteed to either return control to us, or to run indefinitely. Libraries might rely on this to clean up file descriptors, etc. afterwards. Such libraries would be broken by the mere existence of try/catch; even if we never actually use it.
That said, I'm a big fan of pattern-matching, so it would be nice to have in Python, rather than crude approximations like '{pattern1: A, pattern2: B, pattern3: C, ...}[myVal]'
[0] https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...
Time to refactor the project I am currently working on that is loaded with `str.format()`
s = "this is {}"
print(s.format("possible"))
but you cannot do that with f-strings because they are resolved on definition, so you could do something like this: for message in messages:
print(f"The message is {message}")
But not this: s = f"The message is {message}"
for message in messages:
print(s)
This is the same drawback of JavaScript's Template Literals [0].EDIT: Fix syntax in examples.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
x, y = 1, 2
print(f'{x=}, {y=}')