Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #84849 > unrolled thread

Re: The Most Diabolical Python Antipattern

Started byTim Chase <python.list@tim.thechases.com>
First post2015-01-29 11:32 -0600
Last post2015-01-29 11:32 -0600
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: The Most Diabolical Python Antipattern Tim Chase <python.list@tim.thechases.com> - 2015-01-29 11:32 -0600

#84849 — Re: The Most Diabolical Python Antipattern

FromTim Chase <python.list@tim.thechases.com>
Date2015-01-29 11:32 -0600
SubjectRe: The Most Diabolical Python Antipattern
Message-ID<mailman.18285.1422570637.18130.python-list@python.org>
On 2015-01-29 17:17, Mark Lawrence wrote:
> The author is quite clear on his views here 
> https://realpython.com/blog/python/the-most-diabolical-python-antipattern/ 
> but what do you guys and gals think?

I just read that earlier today and agree for the most part.  The only
exception (pun only partially intended) I've found is in functions
that need to return a defined type.  I have one that I call int0()
that is my "give me a freakin' int" function which is something like

  def int0(val):
    try:
      return int(val)
    except:
      return 0

because I deal with a lot of CSV data from client/vendor that has
blanks, "NULL", "---", and plenty of other rubbish to suggest
something that, for my purposes is really just a 0.

Yes, I've been stung by it occasionally, but it's not much trouble to
see that I'm getting a 0 some place that should have a value I need
to extract.

-tkc

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web