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

Common Python Mistakes

toptal.com

Post reply on HN
Print view View original

81–90 of 146 posts

Re: Common Python Mistakes

#81

Post by fragmede »

nine_k wrote: post #72
famousactress wrote: post #37

This list is an excellent summary. If tasked with a #11 I'd probably add the slightly more obscure, but still super painful (when you do run into it) implicit string concatenation: >>> l = ["a", ... "b", ... "c" ... "d"] >>> l ['a', 'b', 'cd']

Still hugely useful when you want to write long string constants. Imho, adding a comma after each list element is a good practice. You can easily swap them, add more, and never run into a an issue you describe: foo = [ "a", "bc", "def", # comma here, too ]

This is preferred! (It also makes diffs more readable)

Re: Common Python Mistakes

#82

Post by nostrademons »

stefantalpalaru wrote: post #51
nostrademons wrote: post #35

Earlier quoted context omitted.

Not really - Javascript was designed to be interpreted, and yet V8/SpiderMonkey/Nitro all JIT-compile it down to machine code, sometimes very effectively.

When people talk about "compiled" vs. "interpreted" they usually mean AOT compilation, not JIT.

Then Java and .NET are considered "interpreted"? And Android under Dalvik is "interpreted", but under ART is "compiled" (using Java as the language, which I'd always thought of as compiled, yet apparently is interpreted under your definition)? What if you embed Clang & LLVM in your application to run C++?

I think this just illustrates the fuzziness of these definitions. A compiler is just a piece of code; you can embed it into another piece of code and run it whenever necessary. Maybe in the world of shrink-wrapped desktop software there was a sharp distinction between AOT compiled languages and interpreted ones, but we haven't lived in that world for a couple decades now.

Re: Common Python Mistakes

#83

Post by hsinger »

crazypyro wrote: post #73
nine_k wrote: post #70

Earlier quoted context omitted.

Just to notice: this text is not targeted at beginners, in my opinion. These are upper-intermediate to advanced level gotchas.

Did they add in "(Note: This article is intended for a more advanced audience than Common Mistakes of Python Programmers, which is geared more toward those who are newer to the language.)" later? Because it states it right near the top of the article.

That note has been in the post since it was first published.

Re: Common Python Mistakes

#84

Post by dalke »

herge wrote: post #55
rnnr wrote: post #36

Earlier quoted context omitted.

It's the comma that determines an expression as a tuple, not the parentheseis.

Not all the time. x = , causes a syntax error, while x = (,) creates an empty tuple.

Under both Python 2.7 and Python 3.3 I get:

    >>> x=(,)
      File "", line 1
        x=(,)
           ^
    SyntaxError: invalid syntax

Re: Common Python Mistakes

#85

Post by vram22 »

In "Common Mistake #2", I'd say that the mistake is fairly obvious to anyone who understands even a little bit about OOP and inheritance. Since class C doesn't define its own variable x, it has to be that it inherits the x in class A, so there's no reason to be surprised that C.x changes when A.x does.

Re: Common Python Mistakes

#86

Post by JadeNB »

pekk wrote: post #78
evincarofautumn wrote: post #77

Here’s a thought experiment for you—think of “common mistakes in language X” as “design flaws in language X” or “ways in which language X is surprising” and what could have been done to mitigate that.

Whether you choose 0-based indexing or 1-based indexing, somebody is going to be confused about indexing sometime.

That's why I always use 7-based indexing, to avoid any possibility of confusion.

Re: Common Python Mistakes

#87

Post by nine_k »

maxerickson wrote: post #79
nine_k wrote: post #75

Earlier quoted context omitted.

In the particular case of constructing several similar functions that do essentially the same thing, lambda is a rather natural choice. Being more explicit and less hacky can well be combined with staying true to functional style: from functools import partial mul = lambda x, y: x*y # could use int.__mul__, too multipliers = [partial(mul, n) for n in range(5)] It does the closure-capturing of n for you.

A function defined with def would work just the same there. It would have a big ugly 'return' in it and be a few characters longer, but it would work the same, so I don't see what lambda brings to it.

Both def and lambda would fail identically in this context.

Re: Common Python Mistakes

#88

Post by radiowave »

vram22 wrote: post #85

In "Common Mistake #2", I'd say that the mistake is fairly obvious to anyone who understands even a little bit about OOP and inheritance. Since class C doesn't define its own variable x, it has to be that it inherits the x in class A, so there's no reason to be surprised that C.x changes when A.x does.

While I agree that the "problem" case can be seen as obvious when considered in isolation, really it's the behaviour of the two cases taken together that can seem inconsistent. Nothing about understanding OOP or inheritance will prepare a person for that.

Re: Common Python Mistakes

#89

Post by Spittie »

dalke wrote: post #84
herge wrote: post #55

Earlier quoted context omitted.

Not all the time. x = , causes a syntax error, while x = (,) creates an empty tuple.

Under both Python 2.7 and Python 3.3 I get: >>> x=(,) File " ", line 1 x=(,) ^ SyntaxError: invalid syntax

From the Python docs (https://docs.python.org/3/tutorial/datastructures.html#tuple...)

> Empty tuples are constructed by an empty pair of parentheses;

And it works fine

    >>> x = ()
    >>> x
    ()
I guess Herge mean that? After all, his argument was that a tuple is not always defined by the comma.

Re: Common Python Mistakes

#90

Post by tomp »

Spittie wrote: post #66
tomp wrote: post #40

Another one: class A(): def __init__(self): self._x = 0 @property def x(self): return self._x @x.setter def x(self, new_value): self._x = new_value Using it: a = A() print a._x # 0 print a.x # 0 a.x = 4 print a.x # 4 print a._x # 0 wait WTF?! The bug was not having `A` inherit from `object`. With old-style classes, properties do not work correctly.

For anyone wondering, this works just fine in Python 3 :)

That's correct, but the post was targeted to Python 2(.7, I assume), so I thought it would fit :)
Post reply on HN