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

111–120 of 339 posts

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

#111

Post by twobitshifter »

dpedu wrote: post #93
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.

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…

I could see lisp programmers missing the commas out of muscle memory

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

#113

Post by kazinator »

rileymat2 wrote: post #46
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 like imports, it tells me what files symbols are coming from, even for built in libraries. Maybe it is that through my work I use a half dozen languages, where it is hard to remember each in detail. I have also worked on a javascript project where there were no imports/requires and the build process created one file. So you had to inspect the confusing build script to even know what was what.

You could fairly easily work with a bunch of .js files that get catenated together by using an editor that can jump to a definition.

Build processes creating one file is the seven decade norm in computing.

Even if you literally don't catenate the .js files into one, they get loaded into one running image one way or another.

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

#114

Post by jstx1 »

andi999 wrote: post #108
savant_penguin wrote: post #68

Earlier quoted context omitted.

Matplotlib is an example of a library with at least two "correct" ways of plotting

Which two ways?

Object-oriented vs Pyplot - https://matplotlib.org/matplotblog/posts/pyplot-vs-object-or...

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

#115

Post by jofer »

jstx1 wrote: post #94
savant_penguin wrote: post #68

Earlier quoted context omitted.

Matplotlib is an example of a library with at least two "correct" ways of plotting

But only one of them is recommended - the one that makes less sense.

How is working with figure and axes objects the one that makes less sense?

Is it really that crazy do set up a figure, axes on that figure, and plot on the axes, returning an artist object for each plotting command?

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

#116

Post by oaiey »

atleta wrote: post #80
oaiey wrote: post #12

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

Not sure if it's irony or not. After all, this is not really accidental string concatenation but an easy to make type error which can go undetected due to the dynamic typing (and the lack of thorough type annotation in most code). The string concatenation in itself should not be a problem as it's really just string constants. (But again, it might be irony exactly because of this :) )

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.

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

#117

Post by doubleunplussed »

dpedu wrote: post #93
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.

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…

Your sarcasm is misplaced. I would prefer a SyntaxError to either of the implicit behaviours.

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

#118

Post by webmaven »

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.

> 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.

Not in comparison to Perl, which usually has multiple ways to do anything, each 'obvious' to different sets of people (each Perl codebase therefore seems to have a distinct dialect based on which 'obvious' alternatives are chosen).

The other direction languages can take that is being contrasted, is there being one non-obvious way to do something.

Python's 'most obvious way' isn't necessarily the fastest/most concise/most efficient/scalable/etc. way to do something in Python, but it will usually be obvious to most Python developers. And although broad styles have certainly developed over time (imperative, functional, OO) as Python has gained power and flexibility, the dictum still largely holds true.

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

#119

Post by dragonwriter »

solox3 wrote: post #60
jstx1 wrote: post #30

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.

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…

> the author used two different ways of hyphenating

No, first, it doesn't use hyphenating at all, it uses hyphens as an ASCII approximation for typographical dashes used to set off a phrase (a distinct function from hyphenation), and, second, in that quote they used one way of doing it: “two dashes set closed on the side of the main sentence and set open on the side of set-off phrase”.

It is an unusual way of doing it—just as with actual typographical dashes, setting open or closed symmetrically would be more common—but it's not two ways.

EDIT: And the third use (in the heading and later in the body) is seperating parts where neither is a mid-sentence appositive phrase, and uses open-on-both sides. So that's not a different way of doing the same thing, it's a different way of doing a semantically different thing.

Actually, I think the dash use makes a good illustration of how the “it” in “one way to do it” is intended.

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

#120

Post by stevesimmons »

rileymat2 wrote: post #46
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 like imports, it tells me what files symbols are coming from, even for built in libraries. Maybe it is that through my work I use a half dozen languages, where it is hard to remember each in detail. I have also worked on a javascript project where there were no imports/requires and the build process created one file. So you had to inspect the confusing build script to even know what was what.

I like the explicit nature of Python's imports.

And especially how I can choose the best way to indicate the sources of names in my code:

   import time
   t = time.perf_counter()

   import time, my_module
   t1 = time.perf_counter()
   t2 = my_module.perf_counter()

   from time import perf_counter as std_counter
   from my_module import perf_counter as my_counter
   t1 = std_counter()
   t2 = my_counter()

   try:
       from my_module import perf_counter
   except ImportError:
       # Fall back to standard implementation
       from time import perf_counter
   t = perf_counter()

   # import time as m  
   import my_module as m
   t = m.perf_counter()
Post reply on HN