Take that, Python.

Yes, I’ve started writing code in Python. The big breakthru for me was realizing that I can overcome one of my worst issues with python, the lack of visible scope annotation, with comments.

def myfunction(somearg):
#{
    print("Yep this is my function")
#}

How come I’m programming in Python at all?

I’ve finally seen the attraction of modern day Python: It’s not the language itself, but the vast array of things Python has its hooks into and which Python – like PHP – gives you sudden and wonderful access to.

Sudden and wonderful because the APIs are usually very clean, while my beloved Perl requires you to perform gymnastic semantics to get things up and running.

With Perl, you pay up front for smoother sailing down the line – you get more mileage out of your Perl “use” than your Python “import”, in the long run. Python programmers just find the next module to “import” and accept bloat instead of leg work.

Perl used to have CPAN for obtaining modules, but my experience the last few years has been that CPAN modules are increasingly abandoned, copious in number and wanting in documentation, perhaps as a result of the CPAN/RPM conflict (local OS bundling of CPAN modules via RPM and DEB packages has caused many an issue).

Python does’t have anything that truly compares with what CPAN was in its heyday. Any 3 Python programmers can give you 5 or more different ways to “easily” get modules on your system, which will work wonderfully for about 15% of the modules you’re going to wind up trying to install.

But I’ve yet to run into a Python module that introduced anything like the nightmarish dependency trees that some basic CPAN modules have thrown at me lately.

There is still, for me, the issue that the Python language is kind of awful.

Lua and Python are both capable of “supporting OOP”, the way the average human colon is capable of “support a pool cue”. In Lua it means pissing about with metatables.

Both languages strive for cleanliness of presentation. If you write really, really simple code, both languages pull this off quite nicely. But the moment you start trying to do anything not utterly-freaking-trivial all kinds of syntactic excrement crawls out of the woodwork.

Python started out by trying to reduce the amount of markup symbols being used, to make the code look more like text. In C/C++/Java you end a given code statement with a semicolon (;). In Python, just you hit return.

// C version
printf("Hello world\n") ;

# Python version
print("Hello world\n")

You can also use semicolons in Python, but the end-of-line character doubles as an end-of-statement character.

In most cases…

And herein is the rub for me, Python is sometimes smart enough to determine that you can’t possibly have finished a statement, such as

# This will work...
listOfThings = [
'tea',
'milk',
'cookies'
]

# This won't
emptyList =
[
]

# You'd have to write this
emptyList = \
[
]

Now this is minor and petty, but it was almost the very first thing I ran into. For those of you thinking I’m nit picking, that “\” character goes totally against the spirit of “avoid using symbol characters all over the place” and running into it so early on felt a bit like a betrayal of the ideal.

For me the next issue is the whole indentation stuff. Python uses white space counts (how many spaces or tabs infront of a line) to tell when you are continuing lines of text.

We humans do this with written text, for example in email we indent quotes and we distinguish between quote and reply by levels of indentation.

The trouble is, you’re not quoting someone else’s replies here, you are creating the whole thing.

My first take on this has been: Well then make sure you don’t have lots and lots of levels of indentation in your code; make copious use of subroutines.

Sadly: Python has a really expensive overhead for function calls.

The indentation concept works fine when you have only one or two levels, but when you start getting to 6 and more, it actually starts to get a bit difficult to track what indentation level is where, or where you *intended* for indentation to be.

Going back to the mail-quoting analogy, very few people use *just* white space for quoting replies. Most people use some kind of markup, a “> ” or a “| ” or some fancy HTML indentation.

Go dig up a deep-quoting email from your inbox and strip out the markup and look at as just pure white-space indented text and try following that. Bet you’re scratching your head within a few minutes. And yet, Python programmers voluntarily inflict this upon themselves for writing mission-critical computer code. OMFG.

    if something that you need to test for the start condition:
        if not assignedValue:
            if AlternateCalculationAvailable():
                assignedValue = AlternateCalculation()
            if not assignedValue:
                assignedValue = ThirdCalculation()
            if not assignedValue:
                assignedValue = DatabaseValue()
                if not assignedValue:
                    assignedValue = DefaultValue()
                    if assignedValue > MinimumValue():
                        if assignedValue >MaximumValue():
                            assignedValue = MaximumValue()

        if assignedValue < MinimumAllowedValue():
            alternateValue = CalcluateForMinimum(assignedValue)

Now – did I mean for that last test to be out-dented so many levels? Ok – that code is contrived, but I’ve seen plenty of code that looks like it. It’s *begging* for some way to allow you to more easily define scope levels, other than functions.

Lastly, I find the Python language to be crazily out of touch with it’s own paradigm of clean looking code: when laziness has won over, Python resorts to symbols; when verbosity has won over, Python resorts to serious verbosity.

Python uses the “:” character to separate pairs of items. It’s consistent about this through the language. To specify characters 5 thru 10 of “theString”, you write theString[5:10], for a dictionary (hash) you write hash = { ‘a’:1 } etc.

And so it uses it also between a conditional and compound statement, between a function/class declaration and the body. While this particular nuance of language design makes sense if you burrow that deep into the design process, it contravenes the “cleanliness” element.

# Actual python
if skyColor() == 'blue' :
    print("Sky is blue")

# Lua code
if skyColor() == 'blue' then
    print("Sky is blue")
end

For function and class definitions, it does make a sort of sense. It comes close to following the everyday English usage of the semicolon character,

Exhibit A:

class Waffles:
    # here's the definition of class Waffles
    def __init__(self):
        # Kinda abandoned the whole readable code here?

# Print the list of items in somelist, one per line.
for item in somelist.items():
    print(item)

I can sort of see how it works with that for, and it does look nice when you’re writing short lines of code.

But – and this is the meat of this particular argument – in a language that is going out of its way to avoid symbols like ‘;’, the ‘:’ becomes errant and elusive in particularly long or complex statements.

It also introduces a somewhat silly seeming input dependency, consider, in the case of “def” (function definition), it means you have to type two end of statement characters: the colon and the carriage return. DUH.

This last is perhaps so that you can do

def foo(): print("foo()")

Ok, I guess I can see that, but it seems that the more common case should accept the following (note: no colon)

def foo()
    print("Foo")

For the more complex uses – if, for, while etc, Python ought to revert to cleanilness:

# One liner.
for label in labels.items() do print(label)

# Compound version.
for label in labels.items()
    print(label)

Worst offender, the Python ternary operator:

# If the user typed 'hello' then respond 'world', otherwise 'hi'.
response = 'world' if input == 'hello' else 'hi'

(Note: suddenly Python can do “if” and “else” without colons, even handling both on one line???)

Now, while some argue the ternary operator is bad, I think that in attempting to avoid recreating the evil of

response = (input == 'hello' ? 'world' : 'hi')

Python created their very own special evil. In particular, this is a case where English would mandate some form of punctuation to help stipulate the precedence. The first alternative would have been to employ consistency:

response = if input == 'hello': 'world' else: 'hi'.

But given the way they did implement, there is a clear argument for allowing the following in Python:

if input == 'hello' response = 'world' else response = 'hi'

Perhaps the reason this is not done is to help the author/viewer to distinguish the conditional clause (” input == ‘hello’ “) from the effector (” response = ‘world’ “). Many languages use parentheses to do this:

// Javascript
if ( input == 'hello' ) response = 'world' ;

Python’s solution for the ternary operation is just a rabbit hole of badness.

# Does the if apply to "namespace + '::' + name"
# or just to name?

fullname = namespace+'::'+name if namespace else name


# Inverted version, even more confusing.
# Is the programmer trying to prefix name with name::
# when no namespace is present?"

fullname = name if not namespace else namespace + '::' + name


# Here another programmer tries desperately to
# state that he wants either "name" or "namespace::name"

fullname = name if not namespace else namespace+'::'+name

# (apparently, he thinks python uses lack of spaces to
# denote increased precedence).