Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

codereviewdoctor.medium.com

Post reply on HN
Print view View original

51–60 of 339 posts

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#51

Post by tgv »

kazinator wrote: post #18

Not in Lisp! ("foo" "bar") and ("foobar") are lists of length 2 and 1, respectively. (Python copies some bad ideas from C. Another one is having to import everything you use. It seems that since Python is written in C, its designer took it for granted that there will be something analogous to #include for using libraries, even standard ones that come with the language.) Implicit string literal catenation is tempting…

The difference is: in C, it's pretty unlikely someone wants to add strings. I suppose it's even illegal in the later C versions.

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#52

Post by geofft »

bcrl wrote: post #24
jollybean wrote: post #16

Earlier quoted context omitted.

5% of 'released' software is quite a lot, more importantly it's a class of errors that definitely should not exist. This is a 'bug' in the language effectively there just isn't any real upside. Python has a few of these things, which is really sad.

It's a class of error that would be caught by even the most basic testing. A better title for the article is that 5% of 666 Python repos have typos that demonstrate the code in them that is completely untested. It doesn't matter which language it is: untested code is untested code in any language.

The errors were usually in tests themselves. Are you arguing that tests need their own tests to test that they are testing the right thing? Usually I think people believe that tests do not need to be tested and should not be tested, i.e., that you measure "100% coverage" against non-test code alone.

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#53

Post by samhw »

voltagedivider wrote: post #45
ErikCorry wrote: post #14

Earlier quoted context omitted.

Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

Isn't that common for all/most languages that don't require explicit typing?

It would be impossible in any language that requires either explicit typing or some kind of 'let' keyword. (Or, in the fringe case, a language like Go which uses a different operator for initialisation-plus-assignment.)

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#54

Post by Spivak »

kazinator wrote: post #18

Not in Lisp! ("foo" "bar") and ("foobar") are lists of length 2 and 1, respectively. (Python copies some bad ideas from C. Another one is having to import everything you use. It seems that since Python is written in C, its designer took it for granted that there will be something analogous to #include for using libraries, even standard ones that come with the language.) Implicit string literal catenation is tempting…

I'm gonna disagree on the import thing. Compared to Ruby where requires are magic bags of metaprogramming bullshit, Python is much much easier to reason about. It takes some getting used to that require 'json' actually adds methods to existing classes.

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#55

Post by rikatee »

tyingq wrote: post #6

Seems expected, as linters can't be sure when it's not intentional. Like this request to pylint: https://github.com/PyCQA/pylint/issues/1589 Is there usually enough context for a linter to make an educated guess?

can do a good job at allowing long urls for example, but would be whack a mole trying to cater for "all" purposeful implicit string concatenations

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#56

Post by mikepurvis »

thaumasiotes wrote: post #31
mikepurvis wrote: post #22

Earlier quoted context omitted.

I would have thought it would be a no-brainer to just ban it and insist on an explicit + operator. I'm pretty surprised that issue was so flippantly closed.

> I would have thought it would be a no-brainer to just ban it and insist on an explicit + operator. Maybe as a matter of linting. As a matter of language design, I think + for string concatenation is a big mistake; using different symbols for numeric addition and string concatenation is something Perl got right.

Yes, I meant as a matter of linting. I can understand the arguments being different for the language as a whole, particularly when legacy compatibility is a consideration.

But my impression using pylint is that its default settings are wildly opinionated, hence the surprise that this wouldn't have fallen under that umbrella.

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#57

Post by samhw »

jstx1 wrote: post #37
ErikCorry wrote: post #14

Earlier quoted context omitted.

Misspelling a variable on the lhs of an assignment just causes a new variable to be created with the new name. That's a lot worse in my book.

That’s a complaint against the entire type system, nothing to do with misspelling.

It has nothing to do with the type system? It's an issue with implicit declaration. You could very easily require explicit declaration while retaining the selfsame type system.

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#58

Post by dnautics »

silisili wrote: post #50
colpabar wrote: post #34

Earlier quoted context omitted.

I was going to comment something like "who would even use this?" and then I remembered that I have in fact used that feature :) It's a somewhat "nice" way to write long strings and keep the code from getting too wide. I never did it inside an array, but I found breaking up a long string into smaller ones and wrapping them in parens without a comma was convenient, for things like error messages. But that's just what c…

Why not just use plusses? Or perhaps a join func, which would accomplish the same. I get the use case as you described it, but it just seems like minimal effort to accomplish and have some semblance of explicit/safety.

or if that's the use case, require the whitespace to include a \n or \r\n... It's not like python doesn't have significant whitespace already.

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#59

Post by shultays »

colpabar wrote: post #34
oaiey wrote: post #12

I am a bit in shock. Accidental string concatenation. Python just lost a lot of reputation in my brain.

I was going to comment something like "who would even use this?" and then I remembered that I have in fact used that feature :) It's a somewhat "nice" way to write long strings and keep the code from getting too wide. I never did it inside an array, but I found breaking up a long string into smaller ones and wrapping them in parens without a comma was convenient, for things like error messages. But that's just what c…

You could have the same behavior by enforcing + operation in between

  mylongstring = "hello" +
    "world"
No idea if python's way of indentations allows this but sounds like it should

Re: 5% of 666 Python repos had comma typo bugs (inc V8, TensorFlow and PyTorch)

#60

Post by solox3 »

jstx1 wrote: post #30
usrbinbash wrote: post #11

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.

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 obvious way. And the philosophy here still applies: when you read anyone else's python code, the obvious way is probably doing the obvious thing. I think that is the more appropriate takeaway from PEP 20.

Post reply on HN