Sure, they have different semantics. But the Zen of Python suggestion isn't usually interpreted to accept, say, a 99% overlap in functionality.
> Special cases aren't special enough to break the rules. > Although practicality beats purity.
The entire zen is self-contradictory, and people are well aware that python breaks the "rules" in some places. That doesn't make the guidelines bad, nor does it make the fact that they guide most of the language and its design less true.
Having 2 ways of defining string constants is useful. And given that practicality beats purity and all, its acceptable to violate the Zen when its sufficiently useful.
Here's the thread:
t0mbstone: shouldn't "arbitrarily deprecate functionality that could have easily been supported"
dragonwriter: They should be because of the Zen of Python.
eesmith (me): but Python does support old functionality, so don't place much weight in how to interpret the Zen of Python as it applies to (C)Python development.
I did not say exactly that because I thought the inference was easy to make given the g'parent threads.
> but Python does support old functionality
is completely compatible with "should deprecate functionality that could have easily been supported". There should be only one way to do it is correct. Under the zen, you should bias towards deprecation. That doesn't mean deprecate every old functionality always. Indeed if there are compelling reasons not to deprecate something (the maintenance cost truly is zero, it is infeasible, the new functionality only covers a subset of uses, etc.) you shouldn't!
The python mailing list and peps have a good bit of discussion about most backwards incompatible changes from py2 -> 3 (and more recent ones, like adding new keywords).
It's in a parallel thread because it's a response to t0mbstone's statement that Python developers should have done more work to support backwards compatibility.
I am not saying that Python should "deprecate every old functionality always", but that is what dragonwriter seems to be arguing.
dragonwriter made a different argument about why to drop backwards compatibility, based on an interpretation of the Zen of Python. My response on this thread is to say that that interpretation of the Zen of Python is not valid, or at least weak, given that it does not explain Python's own development history.
Something that I am sure that you agree with.
I don't see where your views disagree with mine.
Those all have different semantics. They aren't the same thing. In python 3, `''` is a unicode string. `b''` is a byte-string, `''''''` is a multiline unicode string, and `r''` is a string where backslashes are handled specially (which is useful for storing regexes and escape sequences in a human readable way).
Each of those is the obvious way to do the thing. Note that the rule isn't "one way to do things" but "one obvious way". Its possible to generate a multiline string by joining a bunch of lines with `\n`, but its more obvious to use the enter key.
>I can think of at least four: fmt % args, fmt.format(args), string.Template, and f"fmt".
Indeed, and most would argue that % formatting should be deprecated (and would have been, if the stdlib logging module didn't rely deeply on it). Format strings and f strings, are approximately equivalent, but strings.Template objects serve a different purpose.