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

Anti-Patterns in Python Programming

lignos.org

Post reply on HN
Print view View original

141–150 of 242 posts

Re: Anti-Patterns in Python Programming

#141

Post by zo1 »

kyllo wrote: post #139
zo1 wrote: post #128

Earlier quoted context omitted.

The expression presented in the parameter list is only evaluated once, and that is when the method is defined. The confusion is that people assume the expression is evaluated every time the method is called.

The confusion is that people assume the expression is evaluated every time the method is called. Because that's how it works in a lot of other languages, such as Ruby and Javascript.

I doubt that's the only reason. I fell for it myself at first without ever seeing a line of Ruby. It initially feels intuitive, and that's why I think most fall for it.

Re: Anti-Patterns in Python Programming

#142

Post by rmrfrmrf »

tomp wrote: post #95
shadowmint wrote: post #80

Mmm... you should always use 'if x is not None:' imo. It's very common for libraries to make values evaluate to False, and very easy to get bugs if you just lazily test with 'if x'. Sqlalchemy springs to mind immediately as one of the common ones where using any() and if x: is a reeeeeallly bad idea; there are plenty of others. I'm pretty skpetical about modifying your coding behavior based on what libraries you happ…

Especially taking into account the more bizarre bugs (features?) of python: (bool(datetime.time(0)), bool(datetime.time(1))) == (False, True) I always consider `if x:` a bug, unless x can only be a boolean. Furthermore, it seriously hinders readability and clarity of the code.

> I always consider `if x:` a bug, unless x can only be a boolean.

Oh, like this? ;)

   var eventA = new Date(), eventB = new Date();

   if (!parseInt((eventA - eventB) / 1000)) {
     console.log("these events occurred simultaneously");
   } else {
     // troll harder with confusing use of 'asynchronous'
     console.log("these events occurred asynchronously");
   }

Re: Anti-Patterns in Python Programming

#143

Post by pyre »

mbell wrote: post #103
pyre wrote: post #94

Earlier quoted context omitted.

It has something to do with mutability, because if an object is immutable, the behavior of Python matches what the naive developer expects. It's only mutable objects that break those expectations. Don't even get into unexpected behavior in classes: In [1]: class A(object): ...: l = [] ...: In [2]: a, b = A(), A() In [3]: a.l.append("Something") In [4]: a.l Out[4]: ['Something'] In [5]: b.l Out[5]: ['Something'] In [6…

The other scoping issue in python that always struck me as strange is that loop variables aren't scoped to the loop, they continue to exist after the loop completes. I can see the logic for this feature even if I don't agree with it, but what I really don't get is that the loop variables are not defined if you iterate over something that is empty: >>> for item in [1]: ... print item 1 >>> item 1 >>> for i in []: ...…

Then there's for-else:

    In [1]: for i in []:
       ...:     pass
       ...: else:
       ...:     print 'Else!'
       ...:
    Else!

    In [2]: for i in []:
       ...:     break
       ...: else:
       ...:    print 'Else!'
       ...:
    Else!

    In [3]: for i in range(2):
       ...:     break
       ...: else:
       ...:     print 'Else!'
       ...:

    In [4]: for i in range(2):
       ...:     pass
       ...: else:
       ...:     print 'Else!'
       ...:
    Else!
The syntax could be interpreted as:

  if len(l) == 0:
    print "Else!"
  else:
    for i in l:
      pass
The "catch cases where a `break` is triggered" case isn't common enough for this syntax feature to be encountered very often, leading to confusion when people come across it (though at least it's not a bug where a common use-case has weird behavior to new-comers).

Re: Anti-Patterns in Python Programming

#144

Post by klibertp »

hcarvalhoalves wrote: post #136
klibertp wrote: post #16

Earlier quoted context omitted.

It's not weird, it's wrong: In [1]: "a string r".split(" ") Out[1]: ['a', '', '', '', 'string', '', '', '', '', 'r'] In [2]: "a string r".split() Out[2]: ['a', 'string', 'r']

Split without argument is equivalent to: >>> filter(None, " quick hack for split".split(" ")) ['quick', 'hack', 'for', 'split']

Yeah, or re.split(r'\s+', ...), or something - the issue here is that you need to know about this.

From the comment a few levels up I understood that the code which used the str.split with " " argument didn't signify that someone who written it knew about its semantics. If he did and it was really what was intended then ofc it's completely ok, but if not, it can easily lead to bugs.

For example, if the user is required to input several ints separated with whitespace, this:

    map(int, input_str.split())
will rise only in expected cases, while this:

    map(int, input_str.split(" "))
can lead to rejecting correct input just because someone pressed space twice. It's very frustrating for the user, too, because whitespace are hard to spot visually.

So, I don't know if this qualifies as antipattern, but I think if I saw .split(" ") instead of .split() in the code I'd at the very least expect the comment explaining why it's used.

Re: Anti-Patterns in Python Programming

#145

Post by glimcat »

shadowmint wrote: post #80

Mmm... you should always use 'if x is not None:' imo. It's very common for libraries to make values evaluate to False, and very easy to get bugs if you just lazily test with 'if x'. Sqlalchemy springs to mind immediately as one of the common ones where using any() and if x: is a reeeeeallly bad idea; there are plenty of others. I'm pretty skpetical about modifying your coding behavior based on what libraries you happ…

    "Explicit is better than implicit."
If you mean is not None, you should say is not None.

It's fast and readable and there are no "just be aware that" disclaimers to tack on afterwards.

Re: Anti-Patterns in Python Programming

#148

Post by takeda »

noobermin wrote: post #147

Question, how do you over multiple long lists (in python 2) especially if zip itself takes a long time to zip them, for example.

You use Python 3.

J/K, while this is technically a limitation of Python 2, there actually is izip in itertools package which is a generator and works in similar way to zip in python 3.

Re: Anti-Patterns in Python Programming

#149

Post by parham »

LyndsySimon wrote: post #121
parham wrote: post #32

Earlier quoted context omitted.

Even shorter, nice. How about this one liner, the last bit is looking a bit messy any ideas? print " is in the lyrics \n".join([set(lyrics_list) & set(words)]), "is in the lyrics"

Just because it can be written as a one-liner doesn't mean it should be written as a one-liner :) Don't ever do this. print('\n'.join(['{} is in the lyrics'.format(word)) for word in (set(lyrics_list) & set(words))])

I never said it should, it was a challenge.

Re: Anti-Patterns in Python Programming

#150

Post by jules »

jevgeni wrote: post #138
njharman wrote: post #105

Earlier quoted context omitted.

I'm in the camp that if your list comp needs more than one for clause, it's complicated enough to be broken out into actual for loop.

Everybody, listen to this person!

Then it turns into this:

    x = []
    for word in words:
       for letter in word:
          x.append(letter)
Which in addition to being far more verbose and less readable, is also less efficient.
Post reply on HN