Python pains, part 3

Another thing I miss is perfect matching in in and not in operators. And when I say ‘perfect’, I mean prolog. Yes, I’m mad at python because it’s not prolog. Just take a look at this wonderful code:



Neat, eh? So, why can’t I do this, then?



(Yes, I know what the underscore variable in python is for, just pretend you don’t and roll along, ok?)

The nastiest thing about this issue is that it is not universally solvable. Once you’ve implemented a special magic matching function for this particular case, there will be someone who wants to write:



If the whole tuple on the left hand side is defined, one can do the matching perfectly in python. If some parts ain’t, one cannot and has to write an awkward external matching/traversal function. Too bad!

Python pains, part 2

Binary operators are not directly reimplementable, this ain’t Ruby. Some of them can be changed implicitly with a bit of __smth__ magic, others are implemented in the class of one side with a parameter of the other side—and it happens that I often need it the other way around. Suppose the idea of the script is to open the file, read all the lines, stick them together, strip the result, parse it, perform some xpath and create an new element for each element found that way. Easy? Yes. Realistic? Well, the reroot2nonterminals transformation generator is written that way. What do we see there?



And how this would have looked like in my dream python?



Yeah, I know, I know. The problem is inhererent and not really the sole fault of python. However, python already has that nifty self mechanism, which eliminates the difference between a.method() and method(a), and that duality is commonly exploited with string module, for instance. The only thing I need here is two selfs for binary expressions. Or more, for n-ary… Or even…



(The ElementTree is intentionally left out for its side effects, don’t bother). This code actually works, with some magic woven in the Wrapper class. Anyway, if any language ever does this kind of meta-programming naturally, it would be beyond good and evil, I could honestly retire as a language engineer, shave my head, get a peg leg and become a pirate ninja. For now at least it is implementable as meta-hack.

Python pains, part 1

I’ve been a devoted python hacker for almost a decade, and I don’t plan to back off (at least unless Python 3000 forces out 2.x). I program in dozens of other languages, but whenever I need to hack something up, python’s almost always the choice for me. Still, there are things I miss/dislike about it, and I plan to dedicate a couple of posts to them.

The first thing I don’t like is the semantics of list methods. Those methods always disrupt the fp-ish flow of my script. I want to write:



But I have to write:



And that only if I won’t need the original value of a!

The point is: if I ever want to mutate the original list, I’d be willing to write something like a = a.reverse(). On the other hand, assuming that this is what I always want is far-fetched and limiting to my functional way of thinking.

The universal solution would be to make a library of wrappers like this:



Which is ugly (see for yourself), not integrated (a.append(b) vs append_(a,b)) and involves a lot of copying—more than probably really required. So, for better or worse, I end up each time implementing only wrappers specific to my current app.