DEV Community: Christian Selig

My (Least) Favorite Python Quirks

Christian Selig — Wed, 03 Feb 2021 18:08:37 +0000

A couple language ergonomics issues that have given me trouble in my few years of writing Python.

Declarations are executed

This is one that makes sense after you think about what's happening, but I think it's easy to get wrong the first time.

One example is the following:

class MyClass:
  def __init__(self, data={}):
    self._data = data

  def set(self, k, v):
    self._data[k] = v

  def get(self, k):
    return self._data.get(d)

  def remove(self, k):
    self._data.pop(k, None)

  def get_count(self):
    return len(self._data.keys())

A = MyClass()
A.get_count() # 0
A.set('a', 1)
A.get_count() # 1

B = MyClass()
B.get_count() # 1

A.remove('a')
A.get_count() # 0
B.get_count() # 0

If you experimented further, you would see that the contents of _data is being somehow kept in sync between both instances of MyClass.

But interestingly:

C = MyClass({})
C.get_count() # 0

What happened is that Python gets class and function definitions by executing a file line by line, which means that the default value of data in the __init__ method is actually instantiated. All instances of the class that use the default value mutate and read from the same object, effectively making it a class variable.

This is confirmed by:

A._data is B._data # True

Avoiding this involves doing something obtuse like:

class MyClass:
  def __init__(self, data=None):
    if data is None:
      self._data = {}
    else:
      self._data = data

...

Scope of loop variables

Unlike many languages, "loop variables" in Python stay in the local scope after the loop is exited. This can lead to some unexpected behavior:

def fun():
  i = 0
  arr = [1, 2, 3]

  # lots of code

  for i in range(len(arr)):
    # do some stuff

  # more code

  return arr[i]

fun() # returns 3

While this example is pretty contrived, the general idea is that this behavior of loop variables can lead to weird and hard-to-track-down bugs (including this example of shadowing previously declared local variables).

Another complication: if there's nothing to loop over, loop variables won't be assigned at all. For example the first line of main() below runs without error but the second line will cause NameError: name 'x' is not defined to be raised.

def fun(l):
  for x in l:
    print(x)
  return x

def main():
  fun([1, 2, 3])
  fun([])

Even other interpreted and non-curly-brace languages avoid these troubles, e.g. Ruby:

3.times do |x|
  print x
end

x # NameError (undefined local variable or method `x' for main:Object)

Function chaining is hard

When it comes to working with data structures, Python's provided functions and methods aren't very consistent. Take lists for example: the List class has methods that change it in-place, but for many operations you'll need to use list comprehensions which return new lists and have a unique syntax. For other operations you might want to use filter and map, which are functions (not methods of the list class). And there are other scattered inconsistencies, for example the fact that join, a function for working with lists, is a string method instead of a list method.

As an example:

def slugify(string, bad_words):
  words = string.split()
  words = [w.lower() for w in words if w.isalpha() and w not in bad_words]
  return "-".join(words)

slugify("My test 1 string", set(["dang", "heck"])) # "my-test-string"

For people familiar with Python this probably looks natural, but even still the code requires careful reading to understand each transformation the function is doing (and this is for a simple example).

In other languages this kind of code is more natural. Ruby for example has more consistent methods that allow for chaining:

def slugify(string, bad_words)
  string.split()
    .map(&:downcase)
    .select { |w| w.match(/^[[:alpha:]]+$/) }
    .select { |w| !bad_words.include? w }
    .join("-")
end

slugify("My dang test 1 string", Set["dang", "heck"]) # "my-test-string"

As an example from the functional world, Clojure strongly supports function chaining with consistent APIs and the threading macros -> and ->>.

(defn slugify [string bad-words]
  (->> (str/split string #" ")
    (filter #(re-matches #"^[a-zA-Z]*$" %))
    (remove bad-words)
    (map str/lower-case)
    (str/join "-")
  )
)

(slugify "My dang test 1 string" (set '("dang" "heck"))) ; "my-test-string"

Controlling SVG Draw Order in D3

Christian Selig — Tue, 26 Jan 2021 09:10:45 +0000

Sooner or later when working with D3 you'll find yourself in a situation where you need to change how elements overlap each other. Most people (including myself) will first try setting the CSS property z-index, but it turns out unfortunately SVG elements don't respect this property.

The order in which SVG elements are drawn determines the order in which they appear (an element drawn last will appear "over" any other elements it overlaps). The draw order of SVG elements follows a simple rule: elements that appear first are drawn first.

For example, take the following code snippet:

The resulting HTML looks something like:

<svg>
  <circle fill="green" r=50 cx=75 cy=100></circle>
  <rect fill="blue" width=80 height=80 x=85 y=60></rect>
</svg>

The green circle appears before the blue square, so it is drawn first and appears below.

D3's `raise` function

If we wanted to make the blue square appear on top, we could just reverse the order that the elements are created in the code. This works fine for this simple example, but when the code gets more complicated (and especially if we're working with abstractions we've written) we want to control draw order without having to change the order of our code.

To this end, we can use D3's selection.raise() function:

Which results in the HTML:

<svg>
  <rect fill="blue" width=80 height=80 x=85 y=60></rect>
  <circle fill="green" r=50 cx=75 cy=100></circle>
</svg>

The green circle now appears after the blue square in the HTML, which means it appears on top of the square in the rendered SVG.

We can further illustrate this by calling raise() on element mouseover (try hovering over the shapes below).

Ordering and SVG Groups

SVG groups are often used to organize elements in a chart. We can use groups as another way to control draw ordering. In the below example the green circle appears above the blue square despite the fact that is appears before the square in the code.

This is because we've added the circle to group2 and the square to group1, and group1 appears before group2. Take a look at the HTML:

<svg>
  <g class="group1">
    <rect fill="blue" width=80 height=80 x=85 y=60></rect>
  </g>
  <g class="group2">
    <circle fill="green" r=50 cx=75 cy=100></circle>
  </g>
</svg>

Now however we'll have a problem if we try to bind raise() to element mouseover. Notice in the below example that hovering over the shapes does nothing:

This is because raise only changes the order of the element within its parent group. In this example each group only has one element, making raise a no-op.

To make this work we could bind raise to the parent group mouseover, but this might be a little weird because the group doesn't necessarily have the same shape as the child element. A clean way to do it would be to have a function that raises the parent group on element mouseover. All we need to change then is our mouseover callback from d3.select(this).raise() to d3.select(this.parentNode).raise().

Conclusion

Hopefully these examples help clear up how SVG draw order works! Keeping these simple rules in mind can help you exert finer control over the details when working with complicated visualizations.