211–220 of 339 posts
Earlier quoted context omitted.
> it sounds like you're expecting "two" and "three" to be separate list elements I'd expect that to be an error.
Funny enough, in dynamic languages i expect it to do something unexpected and unwanted. This is why i like Go/Rust. I detest the implicit warts of these languages.
Literally the second item in the "Zen of Python" ( https://www.python.org/dev/peps/pep-0020/ ): Explicit is better than implicit. And yet, s = ["one", "two" "three"] will implicitly and silently do something, that is probably wrong most of the time.
I mean the zen being wrong is kind of a meme at this point. The whole “only one obvious way to do it” isn’t just false but the exact opposite is true. Python is one of the most flexible languages with many many ways to do the same thing; more than any other language I can think of.
I knew Python wasn't for me in my first foray into it when I fired its REPL and then went to exit it with control-C or whatever and it literally printed out the right way to do it but then didn't do it. Python was more interested in having me do things a certain way even when it knew what I intended to do, just to be a twit.
The high-level goals of python end up creating these little syntactic landmines that can get even experienced coders. My personal nomination for the worst one of these is that having a comma after a single value often (depending on the surrounding syntax) creates a tuple. It's easy to miss and creates maddening errors where nothing works how you expect. I've moved away from working in Python in general, but I think t…
A lot of people in this thread are using this to make fun of Python, but the exact same issue exists in something like c++, here's some I fixed recently: https://github.com/UWQuickstep/quickstep/pull/9 https://github.com/tensorflow/tensorflow/pull/51578 https://github.com/mono/mono/pull/21197 https://github.com/llvm/llvm-project/pull/335
Also, I personally don't mind this approach to string concatenation. I think it's a fine compromise between easy formatting and clarity. I was whining about a corner case of tuple construction - which as far as I know is not a feature of any other language.
Earlier quoted context omitted.
Unfortunately no irony. I come from a programming platform (C#) where productivity is a key element of language design. I highly doubt that Anders Heijlsberg would have accepted such a error prone concept like a literal free implicit operator on a key type like strings.
Well, I guess it's true for most language that productivity is intended to be a key element of design. (For python, definitely. But I also remember James Gosling saying this about Java.) This implicit concatenation seems to come (inherited?) from C. I kind of remembered that some languages do support it for braking strings into multiple lines conveniently. I'm a bit surprised that it works even on line (I've never us…
What is inconvenient about just adding a + at the end or beginning of the line?
Literally the second item in the "Zen of Python" ( https://www.python.org/dev/peps/pep-0020/ ): Explicit is better than implicit. And yet, s = ["one", "two" "three"] will implicitly and silently do something, that is probably wrong most of the time.
For those looking to avoid this specific problem, there is a flake8 rule: https://pypi.org/project/flake8-no-implicit-concat . More broadly, the https://codereview.doctors makers are making the point that their tool caught an easy-to-miss issue that most wouldn't think to add a rule for. A bit of an open question to me how many of those there really are at the language level, but still seems like a neat project.
Also all but 1 of the issues they found relates to test code, it seems people are a little less careful compared to functional code. Also in terms of mistakes codereviewdoctor twice linked to the same issue in their blog https://github.com/tensorflow/tensorflow/issues/53636 and raised the PR to the wrong project https://github.com/tensorflow/tensorflow/pull/53637 (I guess Tensorflow vendors Keras, easy mistake)
Also a factor that bugs in functional code are more visible, both during development and to users once shipped. So there may have been an equal number or more such bugs in the non-test code, that just didn't remain in the code base for this long.
Earlier quoted context omitted.
Hmmm, it sounds like you're expecting "two" and "three" to be separate list elements because of some sort of implicit behavior due to being written in a list context. This is the opposite of what "Explicit is better than implicit" means. This is a list and you must explicitly place a comma when you want to start a new element in the list. Is there ever a time a new element follows a previous one and is NOT separated…
No, we don't want it to implicitly be a list item. We want it to fail as invalid syntax. If I wanted the two and three strings to be combined, I would have /explicitly/ used an operator for that. It's the implicit behavior of that which is the problem.
Earlier quoted context omitted.
Notice that, in the original quote, There should be one-- and preferably only one --obvious way to do it. the author used two different ways of hyphenating (three, if you count the whole PEP 20). PEP 20 is clearly not meant to be taken as law. Nor PEP 8. Nor PEP 257. People frequently mistake "one obvious way" with "one way". There are lots of ways to iterate through something, for example, but there is really one ob…
It's not even obvious how to run Python or dependencies in the first place. Even putting aside the 2.7/3.x fiasco (that still causes problems even today), you're left with figuring out wheel vs egg vs easy-install vs setuptools vs poetry vs pip vs pip3 vs pip3.7 vs pip3.8 vs piptools vs conda vs anaconda vs miniconda vs virtualenv vs pyenv vs pipenv vs pyflow.
Earlier quoted context omitted.
I mean the zen being wrong is kind of a meme at this point. The whole “only one obvious way to do it” isn’t just false but the exact opposite is true. Python is one of the most flexible languages with many many ways to do the same thing; more than any other language I can think of.
Except exit. I knew Python wasn't for me in my first foray into it when I fired its REPL and then went to exit it with control-C or whatever and it literally printed out the right way to do it but then didn't do it. Python was more interested in having me do things a certain way even when it knew what I intended to do, just to be a twit .
>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit