I hate NULL and all its variants ... quick hack to alleviate the pain in Python | Hacker News Reader

I hate NULL and all its variants ... quick hack to alleviate the pain in Python

blog.alexn.org

22 pointsbad_user23 comments

In Ruby I defined these on Object. A little ugly if you are doing a long chain, but works fine in many cases.

  def if_present?
    # example: User.find_all_by_something.if_present? || User.find_all_by_something_else
    self  if present?
  end

  def send_if_respond_to(method, *args)
    # example: string_or_nil.send_if_respond_to(:strip)
    send(method, *args)  if respond_to?(method)
  end

http://andand.rubyforge.org/

I like monkey patching NilClass to STFU. Bonus: the code fits in a tweet! http://mobile.twitter.com/qwzybug/status/9033799293

Message-eating nils are one of my favorite features of Objective-C.

Ruby also has inline rescue as well.

  (Banana.find(id).plantation.state rescue nil)

Chain it if when falsity occurs do something else.

  banana = (Banana.find(id).plantation.state rescue nil) || Fruit.find(:banana,id).state

Purely FP lang guys are having a good laugh now. :)

Why? I know short comments are easy, but you have a real opportunity here to teach us something new. Can you elaborate?

I'm assuming b/c purely FP languages have handled this for a long time without the need to program around the language.

Monad comprehensions are not necessarily a trait of purely FP languages.

Yes, in Haskell or F# (the 2 languages I've played with) ... monads are so natural you don't even notice them many times. But this goes both ways, what's natural to do in Python, isn't so in other languages.

Also in this particular case you're not programming around the language ... dynamic OOP languages are all about late-binding, that's their strength. If you're using something like Python as if it were Java, you're missing on lots of useful stuff.

Sorry. My entire statement was an assumption as I have little experience with functional programming outside of fooling around with my xmonad.hs file. I was just responding with that I took from the GP comment.

Functional languages like ML and Haskell use option types instead of nulls, and they have tools to work with option types that go far beyond what most languages have for nulls. For example, in Haskell, that chain of function calls might be written like this:

    find "table" [("class", "search-params")] soup >>=
    findParent "form" >>= 
    find "td" [("class", "elem")] >>=
    find "input" [] >>= 
    get "name"

If the result of any call in the chain is Nothing (equivalent to null), we get Nothing. Otherwise, it keeps on going and (if, for example, the name of the relevant element is "signup") we get Just "signup".

Simulating Haskell's option type is actually the article's proposed solution.

It's kind of funny. Everyone mocks the complexity of monads, yet this guy basically implements his own version of Haskell's Maybe in order to make his code easier.

It's really hard not to gloat.

Monads are wonderful when applied properly, and I think everyone fears Haskell because every I/O api is a monad and composition becomes difficult without having some background on the theory involved.

Ignoring the memo part here and focusing on having None/empty list as a return value, what is the problem of doing:

    soup.find('table', {'class':'search-params'}).findParent('form')\
    .find('td', {'class': 'elem'})\
    .find('input')\
    .get('name') or raise WebUIError("Web interface specification changed")

Shouldn't the boolean expression short-circuit and only raise WebUIError in case the expression returns what he doesn't want to?

Any of those find calls can return None. None does not have a find method.

This sounds more like a design flaw in BeautifulSoup than anything else. The OP is wrong in directing his anger towards NULL/None/nil. (BeautifulSoup should be returning an empty collection, not None.)

Bingo!

This api fail drives me crazy when using BS. Esp since it's otherwise pretty slick.

Oh, you're absolutely right. I thought that BeautifulSoup's find would be lazily evaluated, like Django's Queryset.

What you really want in this case is a way to overload the "." operator. If it were just an alias for call you could change None to respond to call on an undefined method with None. That would sort of short-circuit the chain and avoid these errors.

It might require a few changes elsewhere as you would be getting None where you used to get an error, but relying on the error might have been some lazy programming to begin with.

Rather than localizing change to one api and requiring explicit effort to do so. That makes the change global and transparent, affecting all code (your code, std lib, 3rd party lib).

It's really, really not what you want. Or at least not what the poor guy who has to maintain your poorly monkey patched code.

Not in Python, because you wouldn't globally override it. You would just override the __getattr__ of the appropriate objects and be done with it, and nothing else would be affected. If you want it to be isolated a bit of work with "with" would make it easy.

Though I would go an entirely different direction, personally, something like:

    f = self.find
    result = maybe_apply((f, ('table', {'class': ...})),
                         (f, ('td', {'class': 'elem'})),
                         (f, ('input',)),
                         (self.get, ('name',)))

Explicit is better than implicit. For bonus points, the "query" is now reusable and programmatically manipulable, which in my experience outweighs the ugly factor.

What do you mean by "reusable"?

You're basically using Python as if it were Lisp, which is kind of ugly :)

The "qeury" has been reified as data. Now you can do whatever you want to it, including assign it to a variable.

Sometimes the ugly tradeoff is OK, even in Python. In this case it is still less ugly than the code it is replacing, if you write correct code. Doing one little piddly-ass thing (running one method), then copy/pasting in the same four lines of error handling after every single one, well, it may be aesthetically pleasing on your screen but it's far uglier than what I've shown.

Python has many advantages, but it isn't perfect.

No, what you really want is for BeautifulSoup to do the sane thing and return an empty collection instead of None. It makes no sense to special-case the empty resultset case to return None.

Reply on news.ycombinator.com