

How To Let People Know You're A Bad Python Programmer - joubert
http://artificialcode.blogspot.com/2009/08/10-ways-to-let-people-know-your-bad.html

======
grunt
_Call Perl from Python

This is an oldie but a goodie, but a lot of bad programmers don't realize they
can make their Python code even worse, if they embed a bunch of untested,
legacy, Perl code in it. There is a Perl/Python module that makes this a
snap._

Yes, throw in a Perl slight for good measure. A surer way of endearing
yourself to your fellow _Pythonistas_ , I know of not. This is not unlike what
happens on reddit.com/r/programming, where an opportunity to sneer at Java is
never missed, and every kind soul you encounter will gladly regale you with
tales of the imaginary programs they claim to have written in Haskell or Lisp.

Perl, that miserable little unwanted orphan of a language, has real anonymous,
first-class functions complete with closures. Python, sadly, does not, and
that is an undeniable, glaring defect in the language. And for what reason?
Because its Benevolent Dictator for Life decreed that functional programming--
even in the greatly-diluted form in which one finds it in mainstream languages
--is bad and "unpythonic"--heretical, essentially. He recently lashed out
against tail call optimization, and before that attempted to exile some Lisp
constructs that had been resident in the language for many years, but back-
peddled as soon as his subjects threatened to revolt.

When Python catches up to Perl, Ruby, Javascript and every other decent
dynamic language in this department, then you can condemn Perl as much as you
like. Until that time, hold your tongue.

~~~
jmillikin
_Perl, that miserable little unwanted orphan of a language, has real
anonymous, first-class functions complete with closures. Python, sadly, does
not_

Which Python are you talking about? The language I use has had closures and
first-class functions for years.

~~~
abstractbill
They don't seem to work very well:

    
    
      >>> def foo():
      ...   blah = 42
      ...   def wibble():
      ...     print "blah is " + blah
      ...   wibble()
      ... 
      >>> foo()
      blah is 42
    

Great! Looks like we have real closures!

    
    
      >>> def foo():
      ...   blah = 42
      ...   def wibble():
      ...     blah += 1 
      ...   wibble()
      ...   print "blah is " + blah
      ... 
      >>> foo()
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
        File "<stdin>", line 5, in foo
        File "<stdin>", line 4, in wibble
      UnboundLocalError: local variable 'blah' referenced before assignment
    

Oh. Maybe not.

~~~
arohner
That's a scoping problem, not a closure problem. The issue in this example is
that python doesn't have true lexical scope. It has three scopes: function
level, class level, file level. If you wrote "global blah", it would look at
file level, not the next function level.

I agree it's broken, but it's a different flaw than the closure problem.

------
dkarl
_2\. Never return anything in a function, especially not some type of value
that could demonstrate your function succeeded or failed._

First, why would you do his in a language where the idiomatic way to express
that a function has failed is to throw an exception? Second, this is a pretty
extreme failure and probably rare in (useful) Python code; why complain about
about this when there is a _real, extremely common_ problem in Python
programming: not documenting your exceptions, so users who want to distinguish
between different failure modes are forced to experiment and/or read your
code.

------
alec
> Brag that you called Perl from Python because it was "quicker" to
> experienced Python programmers.

A coworker found that calling out to grep can be faster than using Python's
regular expressions for large amounts of text processing. My first reaction
was to cringe, but it was indeed much faster for this particular problem; I
think I was the bad programmer for reflexively cringing instead of saying
"nice performance hack".

~~~
ubernostrum
There are times and cases where a Perl script is faster than grep. It's
ridiculously heavily optimized for that particular task.

------
CodeMage
_Make up excuses like, "I am used to other people testing my code" (This one
sounds especially good if your a former .NET developer.)_

Why single out .NET? Am I missing something?

~~~
icey
I'm pretty sure this guy is just trying to impress his friends on
codinghorror's comment section.

------
yesimahuman
The one issue I have is with the PEP 8 camel case reference. I can see the
value of everyone keeping the same style while coding, but at the same time
who says that style is the best? In terms of "expecting" that style when using
other's libraries, you still have to read the docs for library to understand
how to use it, so I don't see the ultimate value.

~~~
mgreenbe
Settling on language-wide naming conventions reduces cognitive dissonance.
Naming conventions don't supplant reading library docs, but they support it.
In any case, you have to pick _something_ , and some people will always be
dissatisfied.

The answer to any "who says" question about Python is "Guido van Rossum says".
(In the case of PEP 8, Barry Warsaw says as well.)

~~~
yesimahuman
I agree, but I don't agree that deviating from PEP 8 in terms of naming makes
one a bad python programmer. I've seen so many deviations of these rules in
libraries that if I were to expect a certain style I would be more frustrated
than I am.

------
stuff4ben
Funny, you could replace "Python" with "Java" and it would still make sense. I
guess idiots will be idiots regardless of the language.

~~~
astine
Except for the camel case bit...

------
hubb
a few of these are the same as those mentioned in
<http://news.ycombinator.com/item?id=746873>

i too think the distinction between camel case and lowercase underscore as one
being somehow more readable or better than the other is a little silly.

~~~
Semiapies
I'm shifting to prefer lowercase underscore, but I actually wasn't aware of
that detail of PEP 8, either. Not that I can claim to have built anything
sizable in Python, just lots of little to moderate-sized scripts.

------
n8tron
This post reminds me of PHP 'best practices' :)

------
californiaguy
> Add comments in the doc string or anywhere, that say, this is "magic", or
> "bad" and needs to be rewritten.

These are XXX comments and they're pretty common even with the best
developers. They're so common that pretty much every editor has a syntax
highlighting regex to detect them.

~~~
cturner
I'd go further - it's a good thing to do. It allows you to cruise through and
get your main algorithm going, and then focus on details when you can afford
for your brain to be doing that. I used to get distracted by this stuff and
then forget about the big picture thing I was doing. Sometimes you can eve
stub out lists of things with these as comments and then fill in the gaps as
you're able to. Sometimes I review and realise the initial idea was too
complicated and that I've saved energy.

