{"id":10315,"date":"2022-02-19T13:00:12","date_gmt":"2022-02-19T13:00:12","guid":{"rendered":"http:\/\/TheNextWeb=1380846"},"modified":"2022-02-19T13:00:12","modified_gmt":"2022-02-19T13:00:12","slug":"python-may-be-easy-but-its-a-goddamn-mess","status":"publish","type":"post","link":"https:\/\/www.londonchiropracter.com\/?p=10315","title":{"rendered":"Python may be easy but it\u2019s a goddamn mess"},"content":{"rendered":"\n
<\/div>\n

By industry leaders and academic researchers alike, Python is touted as one of the<\/a> absolute<\/a> best<\/a> languages<\/a> for novice programmers. And they\u2019re not wrong \u2014 but that doesn\u2019t mean that it doesn\u2019t confuse the shit out of programming newbies anyway.<\/p>\n

Take dynamic typing<\/a> as an example. It seems amazing at first: Python literally figures out by itself what sort of value a variable might take, and you don\u2019t need to waste another line of code by telling it. This makes everything go faster!<\/p>\n

At first. Then you mess it up on one single line \u2014 yes, one! \u2014 and your whole project crashes before it\u2019s finished running.<\/p>\n

To be fair, many other languages<\/a> use dynamic typing. But in the case of Python, this is only the beginning of the shit-list.<\/p>\n

Reading code gets messy with implicitly declared variables<\/h2>\n

When I started my PhD a couple of years ago, I wanted to develop an existing software, written by a colleague, further. I understood the basic idea of what it was doing, and my colleague had even written a paper about it as a documentation.<\/p>\n

But I still needed to read through thousands of lines of Python code to make sure I knew which part did what, and where I could put the new features I had in mind. That\u2019s where it got problematic\u2026<\/p>\n

The whole code was littered with variables that were declared nowhere. In order to understand what every variable was there for, I had to search for it throughout the whole file and, more often, across the whole project.<\/p>\n

Add the complication that a variable is often called one thing inside a function, but then something else when the function is actually called\u2026 And the fact that a variable can be intertwined with one class which is tied to another variable from another class which influences a totally different class\u2026 You get the idea.<\/p>\n

I\u2019m hardly alone with this experience. The Zen of Python<\/a> clearly says explicit is better than implicit. But it\u2019s so easy to do implicit variables in Python that, especially in large projects, sh*t hits the fan very quickly.<\/p>\n

Mutable types are hiding everywhere \u2014 even in functions<\/h2>\n

In Python, you can define functions with optional arguments \u2014 that is, arguments that you don\u2019t need to state explicitly afterwards \u2014 by providing a default value. Like so:<\/p>\n

def add_five(a, b=0): return a + b + 5<\/pre>\n
That\u2019s a silly example, I know. But the idea is that you can call the function with one argument now, or two, and it works anyways:<\/p>\n
add_five(3) # returns 8 add_five(3,4) # returns 12<\/pre>\n
This works because the expression b=0 is defining b as an integer, and integers are immutable. Now consider this:<\/p>\n
def add_element(list=[]): list.append(\"foo\") return list add_element() # returns [\"foo\"], as expected<\/pre>\n
So far, so good. But what happens if you execute it again?<\/p>\n
add_element() # returns [\"foo\", \"foo\"]! wtf!<\/pre>\n
Because a list, the [\u201cfoo\u201d] one, already exists, Python just appends its thing to that one. This works because lists, unlike integers, are mutable types<\/a>.<\/p>\n
\u201cInsanity is doing the same thing over and over again and expecting different results,\u201d so goes the common saying (it\u2019s often misattributed to Albert Einstein<\/a>). One could also say, Python plus optional arguments plus mutable objects is insanity.<\/p>\n
Class variables aren\u2019t safe from danger<\/h2>\n
If you thought that such problems are limited to the \u2014 admittedly not so ubiquitous \u2014 case of mutable objects as optional arguments, you\u2019re mistaken.<\/p>\n
If you do object-oriented programming \u2014 that is almost everyone \u2014 classes are everywhere in your Python code. And one of the most useful features of classes of all time is\u2026 (drumroll)
\u2026 inheritance.<\/p>\n
Which is just a fancy word for saying that if you have a parent class with some properties, you can create children which inherit the same properties. Like this:<\/p>\n
class parent(object): x = 1 class firstchild(parent): pass class secondchild(parent): pass print(parent.x, firstchild.x, secondchild.x) # returns 1 1 1<\/pre>\n
This isn\u2019t a particularly brainy example, so don\u2019t copy it into your code projects. The point is, the child classes inherit the fact that x = 1, so we can call it and get the same result for the child classes as for the parent.
And if we change the x attribute of a child, it should change that child only. Like when you dyed your hair as a teen; that didn\u2019t change your parents\u2019 or your siblings\u2019 hair either. This works:<\/p>\n
firstchild.x = 2 print(parent.x, firstchild.x, secondchild.x) # returns 1 2 1<\/pre>\n
And what happened when you were little and mommy dyed her hair? Your hair didn\u2019t change, right?<\/p>\n
parent.x = 3 print(parent.x, firstchild.x, secondchild.x) # returns 3 2 3<\/pre>\n
Ew.<\/p>\n
This happens because of Python\u2019s Method Resolution Order<\/a>. Basically, the child classes inherit everything the parents have, as long as it\u2019s not stated otherwise. So, in Python-world, if you don\u2019t protest in advance, mommy dyes your hair whenever she does hers.<\/p>\n
Scopes go inside out sometimes<\/h2>\n
This next one I\u2019ve stumbled over so many times.<\/p>\n
In Python, if you\u2019re defining a variable inside a function, this variable won\u2019t work outside the function. One says it\u2019s out of scope:<\/p>\n
def myfunction(number): basenumber = 2 return basenumber*number basenumber ## Oh no! This is the error: # Traceback (most recent call last): # File \"\", line 1, in # NameError: name 'basenumber' is not defined<\/pre>\n
This should be rather intuitive (and no, I didn\u2019t stumble over that part).<\/p>\n
But what about the other way around? I mean, what if I define a variable outside a function, and then reference it inside a function?<\/p>\n
x = 2 def add_5(): x = x + 5 print(x) add_5() ## Oh dear... # Traceback (most recent call last): # File \"\", line 1, in # File \"\", line 2, in add_y # UnboundLocalError: local variable 'x' referenced before assignment<\/pre>\n
Strange, right? If Albert lives in a world which contains trees, and Albert lives inside of a house, surely Albert still knows what trees look like? (The tree is x, Albert\u2019s house is add_5() and Albert is 5\u2026)<\/p>\n
I\u2019ve stumbled over this so many times while trying to define functions in one class that get called from another class. It took me a while to get to the root of the problem.<\/p>\n
The thought behind this is that x inside the function is different from the x outside, and so you can\u2019t just change it like that. Like if Albert dreams about turning the trees orange \u2014 that doesn\u2019t make the trees orange of course.<\/p>\n
Luckily, there\u2019s a simple solution<\/a> to this problem. Just slap a global before x!<\/p>\n
x = 2 def add_5(): global x x = x + 5 print(x) add_5() # works!<\/pre>\n
So if you thought scopes only shield variables inside functions from the outside world, think again. The outside world gets protected from local variables in Python, in the same way that Albert can\u2019t color trees orange with the power of his thoughts.<\/p>\n
Modifying lists while iterating over them<\/p>\n
Eh, well\u2026 yes, I\u2019ve managed to run into such bullsh*ttery myself a couple of times.<\/p>\n
Consider this:<\/p>\n
mynumbers = [x for x in range(10)] # this is [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] for x in range(len(mynumbers)): if mynumbers[x]%3 == 0: mynumbers.remove(mynumbers[x]) ## Ew! # Traceback (most recent call last): # File \"\", line 2, in # IndexError: list index out of range<\/pre>\n
This loop doesn\u2019t work because it deletes an element of the list every so often. The list\u2019s end therefore shifts forward. Then it\u2019s impossible to arrive at element number 10 because it\u2019s no longer there!<\/p>\n
One dirty but handy workaround is assigning a silly value to all elements that you want to delete, and then remove them in a next step.<\/p>\n
But there\u2019s a much better solution:<\/p>\n
mynumbers = [x for x in range(10) if x%3 != 0] # that's what we wanted! [1, 2, 4, 5, 7, 8]<\/pre>\n
Just one line of code!<\/p>\n
Note that we\u2019ve already used Python\u2019s list comprehension<\/a> in the broken example above, to invoke the list.<\/p>\n
It\u2019s the expression in the square brackets [], and is basically a short form for loops. List comprehensions are often a little bit faster<\/a> than regular loops, which is cool if you\u2019re handling large datasets.<\/p>\n
Here, we\u2019re just adding an if clause to tell the list comprehension that it shall not include the numbers that are divisible by 3.<\/p>\n
Unlike some of the phenomena described above, this isn\u2019t a case of Python madness. Even if beginners may stumble over this at first, this is Python genius.<\/p>\n
Some light at the horizon<\/h2>\n
Back in the days, coding wasn\u2019t the only pain<\/a> when it came to Python-related woes.<\/p>\n
Python also used to be incredibly slow at execution, running anywhere from 2 to 10 times slower<\/a> than most other languages.<\/p>\n
This has gotten a lot better now<\/a>. The Numpy package<\/a>, for example, is incredibly fast at handling lists, matrices, and the like.<\/p>\n
Multiprocessing<\/a> has gotten much easier with Python, too. This lets you use all your 2 or 16 or however many cores of your computer, instead of just one. I\u2019ve been running processes on 20 cores at a time and, boi, it\u2019s saved me weeks of compute time already.<\/p>\n
Also, as machine learning<\/a> has taken up steam over the past few years, Python has shown that it has places to go. Packages like Pytorch and Tensorflow make this dead easy<\/a>, and other languages are struggling to keep up.<\/p>\n
However, the fact that Python has become better over the years doesn\u2019t guarantee a rosy future.<\/p>\n
Python still isn\u2019t idiot-proof. Use it with caution.<\/p>\n
This article was originally published on Medium. You can read it here<\/span><\/a>.<\/em><\/p>\n
 Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
By industry leaders and academic researchers alike, Python is touted as one of the absolute best languages for novice programmers. And they\u2019re not wrong \u2014 but that doesn\u2019t mean that it doesn\u2019t…<\/p>\n","protected":false},"author":1,"featured_media":10316,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/10315"}],"collection":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10315"}],"version-history":[{"count":0,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/posts\/10315\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=\/wp\/v2\/media\/10316"}],"wp:attachment":[{"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.londonchiropracter.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}