a = 17
print("a=", a)
print("a=" + str(a))
print("a=%s" % a)
print("a={}".format(a))
print(f"a={a}")
# python 3.8 =>
print(f"{a=}")
But, if it sounds like I agree with you, I actually don't. I feel that the Zen of Python has taken on an almost religious level of veneration in people's minds, and leads to all sorts of unproductive debates. One person can latch onto "there should be one obvious way to do it" and another onto "practicality beats purity" and another onto "readability counts." Who's right? All can be. Or none. All could be applied to this particular case.
The Zen of Python is just a set of rough heuristics, and no heuristic or principle in the field of software development applies 100% of the time, IMHO. <= except for this one ;)
In cases like this, different ways to do it (all equally good) are needed to get a good coverage of different tastes in obviousness and different nuances in the task.
The point is not uniformity, but avoiding the unpleasant and convoluted workarounds caused by non-obviousness (thus making the language easy to use).
String formatting is not trivial: there is the split (sometimes architectural, sometimes of taste, sometimes of emphasis) between concatenating string pieces, applying a format to objects, setting variable parts in templates, and other points of view; and there is a variety of different needs (cheap and convenient printing of data, dealing with special cases, complex templates...)
print string.Template("a=$a").substitute(a=a)Python is one of the least "only one way to do things" languages I've used. This even extends to its packaging system, where you can choose between virtualenv, pipenv, pyenv, etc. Same goes for the installation method too, do you want to install Python with Anaconda or use the default method?
As for my personal take on this feature: I think it's really useful. When web-scraping in Python, I oftentimes had to do this:
while True:
html_element = scrape_element()
if html_element:
break
sleep(10)
while not html_element := scrape_element():
sleep(10) for html_element in iter(scrape_element, None):
And pyenv is just a version manager, like rbenv or nvm. I wouldn’t consider its existence confusing, not would I say being able to install something in more than 1 way has any relevance to the zen of Python!
Should Python create some cross-platform Uber-installer so that there is only one download link?
Regardless of what pyenv, the rest of my comment about the complexity of Python's tooling still stands. There's too many choices. I also seen people use pyenv as an alternative to virtualenvs, which is something I have never seen with nvm.
I don't understand why the Python community hasn't coalesced around a single solution to package management that has minimal complexity. It seems like pipenv is the solution, but there is controversy around it and it should have come several years ago. The fact that Python packages are installed globally by default is also pretty terrible, I much prefer it when applications bundle their dependencies. When I do `npm install --global`, the resulting program will always work, regardless of what other packages I have installed on my system.
> Any critiques on Python-the-language?
The point of my original comment was not to necessarily critique the Python programming language, rather it was to point out that adhering to the "zen of Python" is a lost cause because the language/development environment is not designed as a curated experience.
And my original comment did make points about Python-the-language. I talked about how there's many ways to do a single task in Python. One of the responses to it even proved my point:
"Prior to that you could use the special two-argument version of the `iter` function which makes it act completely different than the single argument version: <code sample>".
That unfortunately demonstrates my point.
This is one of the reasons I love Python. It's a great exercise to rewrite the same code imperative, recursive, with generators, with iterables, etc. Python is very good at supporting a wide range of programming styles.
You do know that this:
x := 1
When is an expression allowed to have := in it, is
(x := 1)
(x := 1)
But while there are now two ways of doing assignment, I wonder how often people will actually encounter situations where it's difficult to figure out which choice is better.
[0] https://www.python.org/dev/peps/pep-0572/#exceptional-cases
Every possible line of code has an alternate ugly way to write it. This isn't a valid criticism. Anyone who decides to start writing simple assignment statements like that deserves to be ridiculed for writing ugly code.
Maybe it would have been better to only have a single := assignment operator to begin with. But it's a few decades too late for that.
For what it's worth, := is for expressions only. Using it as a statement is a syntax error. So there won't be a lot of cases where both are equally elegant options.
ninjaedit: indeed https://www.python.org/dev/peps/pep-0572/#why-not-just-turn-...
The new operator (like many Python operators) can only be used in expressions (statements can contain expressions, but expressions are not a subset of statements.)
> The fact that there is now an operator that can only be used in certain statements just makes things more confusing
Because the “=” operator is the thing that defines an assignment statement. Even if this could be resolved unambiguously for language parsers, so that “statement defining” and “within expression” uses didn't clash, it would be create potential readability difficulties for human reading. Keeping them separate makes the meaning of complicated assignment statements and assignment-including expressions more immediately visually clear.
> There should be one-- and preferably only one --obvious way to do it.
There are plenty of ways to do assignments. Walrus assignments are only the obvious way in certain cases, and in general there aren't other obvious ways. For testing and assigning the result of re.match, for instance, walrus assignments are clearly better than a temporary.
I can think of lots of nonobvious ways to do assignments, like setattr(__module__...)
Also, I can't bring myself to call it the walrus operator. Sorry, guys. I had a Pascal teacher ages ago who pronounced it "gets" and that has always stuck.
>>> locals()['a'] = 1
>>> a
1
x = [1, 2, 3, 4]
def foo():
x[0] += 3 # Okay
def bar():
x += [3] # UnboundLocalError
def qux():
x = [5, 6, 7, 8] # Binds a new `x`. def bar():
x += [3] # UnboundLocalError