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

91–100 of 146 posts

Re: Common Python Mistakes

#91

Post by timdierks »

mark-r wrote: post #68
Goosey wrote: post #49

Slightly off topic, but does anyone know of a resource that has 'most common mistakes' for different languages all in one place? It's certainly possible to google for blog posts and stack overflow questions to assemble such a list, but it would be handy to have them all in one place. My use case is when interviewing candidates I often ask them to rate themselves on a scale of 1-5 in the languages they know, and then…

While such a resource would make your job easier, it would make the interviewee's job easier still. They'd just have to memorize all the points in the reference.

At which point they will no longer make these mistakes, and thus are more expert.

Everyone wins!

Re: Common Python Mistakes

#92

Post by dalke »

Spittie wrote: post #89
dalke wrote: post #84

Earlier quoted context omitted.

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.

That's a reasonable deduction. Thanks!

Re: Common Python Mistakes

#94

Post by vram22 »

radiowave wrote: post #88
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.

>really it's the behaviour of the two cases taken together that can seem inconsistent.

Why do you think so? I think that both cases seem consistent, or rather, correct (and therefore this example should not be treated as a common Python mistake), because x is not assigned a value anywhere in class C, and C inherits from A, so it should be clear to anyone knowing OOP and inheritance, that C's x is the same as A's x. (And the same holds true for inherited methods.) Even the OP says that in the post:

>In other words, C doesn’t have its own x property, independent of A.

Re: Common Python Mistakes

#95

Post by ColinWright »

yeukhon wrote: post #53
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']

I never knew you could do that. You don't need the continuation though. >>> l = ["A", "c""d"] >>> l ['A', 'cd']

You need to re-format that with leading spaces to retain the indentation.

Re: Common Python Mistakes

#97

Post by mark-r »

ajanuary wrote: post #76
mark-r wrote: post #15

I've always thought that #1 is a sign of an incorrect operation altogether. If you want to always modify the passed parameter, it doesn't make sense to have a default. If you want to return a modified version of the input, you should make a copy immediately and then you don't get this problem. Doing both an in-place modification and returning a modified object at the same time is just wrong.

A slightly more realistic example: class Bag(object): def __init__(self, items=[]): self.items = items def add_item(self, item): # check the item is valid self.items.append(item) bag1 = Bag() bag1.add('an item') bag2 = Bag() print(bag2.items)

Again, the problem is not what it appears. You're keeping a reference to an existing item rather than making a copy. The results would be just as bad if you passed in an initial list rather than taking the default.

    initial = ['first item']
    bag3 = Bag(initial)
    bag3.add_item('second item')
    print(initial)
I think the surprising thing to most people is that you don't automatically get a copy when you do the assignment. That's how it works in older languages like C and C++, and how it appears to behave when you use immutable objects.

Re: Common Python Mistakes

#98

Post by mark-r »

timdierks wrote: post #91
mark-r wrote: post #68

Earlier quoted context omitted.

While such a resource would make your job easier, it would make the interviewee's job easier still. They'd just have to memorize all the points in the reference.

At which point they will no longer make these mistakes, and thus are more expert. Everyone wins!

Except that you're risking hiring people that know all the trivia but still can't program FizzBuzz properly. The test loses its predictive value.

Re: Common Python Mistakes

#100

Post by codezero »

jordigh wrote: post #96
codezero wrote: post #93

OT but this page hard crashes Safari on iPhone.

File a bug report with Apple? No input should crash a program.

I'll do that. In general Safari doesn't crash so I was letting the OP know for their own benefit as they are in a better position to isolate the cause and work around it.
Post reply on HN