Live data from Hacker News

Common Python Mistakes

toptal.com

21–30 of 146 posts

Re: Common Python Mistakes

#21
post #2

My pet peeve with python is the classic: return x, I have never wanted to declare a tuple without surrounding it with (). Too bad it's not a syntax error in python 3. Also, as opposed to one of his examples, if you are using python 2.7, declare your exception blocks as: except (FooException, BarException) as e: It's forward compatible with python 3, it's easier to read and the syntax errors are clearer.

I have never wanted to declare a tuple without surrounding it with (). No? I do that occasionally, e.g.: x, y = 5, 6

Doing

    (x, y) = (5, 6)
makes it clearer to "visually grep" that it's not a normal assignment though.

Re: Common Python Mistakes

#22

#6 is really confusing. Whenever I encounter something like this my first reaction is that whenever possible such obscure components of a language should be avoided and more verbose/clear code used instead. Programming languages are meant to be read as well as written, and someone relatively new to Python (and many who have used the language for a long time) is certain to get confused about the difference between: re…

Agreed 100%, this type of constructions should be avoided in the first place in favor of more "readable" ones but this happens in a fair amount of code that I've seen (and I keep seeing).

Some of it seems to come from people cargo-culting their knowledge of anonymous and first class functions, so they end up believing that the only way to pass a function around is to construct it anonymously.

Re: Common Python Mistakes

#23
The scoping rules in #4, combined with being able to reference variables before definite assignment, is what leads to the 'variable hoisting' in Javascript.

Is #6 really called 'late binding'? That seems like the wrong term.

Re: Common Python Mistakes

#24

> "Python is an interpreted, object-oriented, high-level programming language with dynamic semantics." I have an issue with that statement. No languages are inherently "compiled" or "interpreted", that's a property of the implementation. If we are talking about CPython here, Python code is compiled to bytecode which is then interpreted. Not unlike Java - with the difference that the main implementation has a JIT and…

High-level is also a relative term (with multivariable semantic, leading to not comparable languages), and the term "object-oriented" is getting less expressive by the day.

Anyway, all of those terms do communicate something, even if tomorrow they may wrongly describe the language.

Re: Common Python Mistakes

#25
And I would have thought that incorrect usage of bytestrings for text and then asking on Stack Overflow about the UnicodeDecodeErrors would be quite common as well ...

Re: Common Python Mistakes

#26

The scoping rules in #4, combined with being able to reference variables before definite assignment, is what leads to the 'variable hoisting' in Javascript. Is #6 really called 'late binding'? That seems like the wrong term.

Please check out http://en.wikipedia.org/wiki/Late_binding to know more.

Re: Common Python Mistakes

#27
I have been bitten by #6 in a similar situation in the past. My solution was the analogue of the rather convoluted

    def create_multipliers():
      def multiplier(i):
        return lambda x: i*x
      return [multiplier(i) for i in range(5)]

    for multiplier in create_multipliers():
      print multiplier(2)
I would still prefer that Python doesn't do this.

Re: Common Python Mistakes

#29

> "Python is an interpreted, object-oriented, high-level programming language with dynamic semantics." I have an issue with that statement. No languages are inherently "compiled" or "interpreted", that's a property of the implementation. If we are talking about CPython here, Python code is compiled to bytecode which is then interpreted. Not unlike Java - with the difference that the main implementation has a JIT and…

> No languages are inherently "compiled" or "interpreted", that's a property of the implementation.

A language and it's implementation are usually designed at the same time. Compiled or interpreted will affect design choices that go into the language. While additional implementations may follow, it can be hard/impossible to design a compiler (machine code, not byte code) for a language that was designed to be interpreted without dropping features (ie eval).

It may be more correct to say 'Python was designed to be interpreted' than 'Python is interpreted'

Re: Common Python Mistakes

#30
post #25

And I would have thought that incorrect usage of bytestrings for text and then asking on Stack Overflow about the UnicodeDecodeErrors would be quite common as well ...

Yeah, bigtime. I'm not sure that would make for a quick, easy countdown list of a blog post, though.
Post reply on HN