Friday, January 19, 2007

Friday Night Link Up

  1. PyPlus

    Creates a python-style C++. This replaces {} with indentation and removes excess parenthesis. Its definately a very interesting project, but how many uses it sees I am not sure of.

  2. Tiger Woods Wii: Doesn't look poopy :: DESTRUCTOID :: Hardcore gaming blog

    One of my favorite games on the Wii has been the golf of WiiSports, but it is very limited and toyish, as fun as it is. The Tiger Woods title looks absolutely fantastic and I've never been a fan of golf or golf video games, but I'll pick this title up on launch day.
  3. WiiCade.com - Flash Games on your Nintendo Wii

    I had hoped someone would do this. Bookmark the website on your Wii and get quick access to lots of web-based flash and java games that are friendly to being played via the Wii and Wiimote.
  4. Nothing But Videos: Man Shoots Electricity Out Of His Hands

    There really isn't much more that I can say about this after the title. He even sets fire to things with his fingertips, and does this on a regular basis!
  5. Offline Gmail and Blogger Using the Dojo Offline Toolkit

    This is a great idea that needs explored more thoroughly. Web apps become more and more widespread and even with the proliferation of always-on connections, we can't forget that things need to work when the network fails, I'm working off solar panels in the mountains, or the world has ended and only patches of ad-hoc networks survive.

    The idea is to enable web applications that can cache lots of data for offline use. I used to abuse Google Reader to do this before the long drives to and from North Carolina, by scrolling across all my hundreds of unread items they would all be downloaded internally and then even offline I would be able to read through them. This kind of functionality needs to be empowered, not accidental.
  6. Firefox 3 Plans and IE8 Speculation - Browsers Heading Apart Again

    I am more interested in how far Firefox 4 will go to providing a unique platform for web applications. Will we open up the embedded SQLite database to javascript in the pages, or bind OpenGL for accelerated rendering into canvas elements?
  7. Levy Interviews Steve Jobs About iPhone - Newsweek Steven Levy - MSNBC.com

    I was going to write about how Steve Jobs is a moron because of the whole "no third party software" thing on the iPhone, but then I realized that I'm sure I would absolutely love the iPhone. Does it point to a larger problem that one of the most important technological minds of our era can only solve the problem by just locking everyone out?

Thursday, January 18, 2007

The Snake Pit is About to Burst

The signs are all over the place. I can count at least five implementations of Python today: CPython, CL-Python, Jython, IronPython, and PyPy. The use of the language is sky rocketting and set to grab real mind-share as the hype over Ruby subsides. Things are looking good for a favorite green snake and british comedy troop reference, aren't they? Trouble is on the horizon in the very ingredients that could push us into true success.

Our community and our very language is in danger of segregation, unless we all do something about it and learn to get along.

One of the most visible dangers (to me) is being ignored for various political, cultural, and non-technical reasons. IronPython's users are increasingly pushing IronPython-only recipes, libraries, and tutorials. No one is talking about the transition of the alternative implemenations to CPython 3.0 compatability. To make matters worse, we still can not define the language without refering to an implementation. This is very unlike the motivations that have made the language and its community so great.


Although it has had measured success in a lot of areas, there is a lot of negative sentiment around IronPython, which is often seen as traiterous to a degree by the open source community members who are active with Python, and don't want to see it making bed-fellows with the Redmond empire. No one cares about getting Zope, Twisted, and lots of other popular projects to work with IronPython, or Jython and even PyPy, for that matter. The disconnect between the traditional Python community and the IronPython community means things like this are ignored, because no one on the traditional side cares and few on the IronPython side know better or consider the rammafications of their actions. We need to consider the language as a whole and understand the value of our many implemenations, especially those larger projects with a community responsibility. Of course, someone should step up to the challenge.

The seperate between the pythons will only grow when 3.0 is released in a few years, pushing the other implementations behind in compatability by many years. This is something less easy to fix than most realize. The other projects simply dont have the resources that CPython does, and will fail to make the updates until many more years after 3.0 is the standard. There is a strong chance that this will lead to a fragmentation of the language, where IronPython might split off when it realizes that:
  • Most of its code is specific to IronPython anyway
  • It is already incompatible with most of the Python code that has migrated to 3.0
  • A major migration of the language to 3.0 will cost and gain as many users as any original changes they might make
Obviously, I am naming lots of problems and few solutions. I wish I had more of the later and less of the former, but sometimes we are not so lucky. What few ideas I do have towards avoiding the problems are not well thought out, probably are missing vital information, or are simply stupid. I won't deny that I'm complaining more than helping, but the former often has to proceed the later. Maybe we have to have a period of whining about the problem before enough people realize that there even is a problem, before we have the right environment to start approaching it. We need to keep a handle on things, but the big dangers are still years down the road.

Consolidation is the key to keeping our head on our collective shoulders. There is a lot of redundant work. There are module being maintained by at least three implementations and updates dont propogate often enough if there is cross over. In many cases, there isn't even enough cross over in the first place to cooperate on! Can you really consider IronPython a Python when you don't have os, pickle, or StringIO? Many of these missing pieces could be brought directly from CPython (licensing permitted, maybe someone can comment on any possible problems there). I believe (corrections are welcome) that PyPy does use many of the pure python modules from the CPython distribution. We can do better and sharing needs to become the norm, not the surprise.

When I write a small library and I use StringIO, i really don't care if someone uses my module over CPython, Jython, IronPython, or PyPy. As a matter of fact, I'd love to see it used on all four! I have to inherently declare no support for IronPython, because I use a standard language module StringIO. People might forget but the stdlib is a part of the language as much as a for loop. If we had Python the language in its completeness and we had no libraries, we wouldn't have anything close to what we have today. Policies need to be put into place for cooperatively sharing between the implementations all the pure python modules that are possible. As long as they are being shared, they don't belong to any one implementation and should be more open to a joint management of their direction, including implementation specific, optional optimizations, such as using the CLR assemblies or Java classes that natively implement much of the functionality. We already have platform specific code branches, so this is not a stretch. The kind of sharing I call for will bring a lot of the work together so that overall we require less resources, yet produce more results.

Non pure-python modules are something more of a problem. How does PyPy handle shared libraries, or IronPython while remaining a pure CLR solution? How does someone take advantage of .Net and Python without excluding the rest of the Python community? We have to make a lot of tough decisions, because no clear solution is on the horizon. We can look to RPython for a lot of advice, and just imagine if we had a conversion path from RPython to C# or directly to CLI bytecode. I don't want to have to rely on everything in pure python, until PyPy is more complete, but I don't want pygame to be stranded tied to C-land. The horizon might be empty, but we need to keep wandering towards it with high chins, just the same.

A little, I wrote about the problems of culture between the traditional Python community members and those embracing and using IronPython. I did not expand on that much here, trying to be more balenced, but I'd like to expand on it in a future post. The more comments I can get about your opinions there, the more interesting the future post will be.

MPAA Lobbying for Home Theater Regulations

A depressing and angering article by the same title: MPAA Lobbying for Home Theater Regulations

I don't have a whole lot to say about this, but it sure did make me angry. It is a little old, but I had filed it away and planned to write about. I feel strongly enough for it that I'll write about it, even if I'm writing about it late.

The basic idea here is that when the MPAA thinks of a home theater, they think in insane terms. If you have a TV over 29", stereo sound, and a couch, they are of the opinion that you owe them money and reporting of the use of your theater, just like the theater at the local mall. That is seriously just fucking crazy.

I use such strong language because this is something to feel very strong about and thus to express strongly.

My favorite quote is "Just because you buy a DVD to watch at home doesn't give you the right to invite friends over to watch it too. That's a violation of copyright and denies us the revenue that would be generated from DVD sales to your friends," said by MPAA head Dan Glickman.

Write your representatives, everyone. Even if you are out of the US, you might have similar things in the legislative pipeline. They like to attack of globally these days.

I Am Gullible

I want to announce that I must be very gullible. Should be important to point out that I have never in my life even heard of the website, BBSpot.com, and so I had no idea they were a satire news site. With the draconian legislation the MPAA and RIAA try to push on us, is it any surprise that when I then read this article I responded without realizing it was a joke? It simply does not seem past them. Thanks to Jay for pointing out my blunder.

Stupid do me think I is.

Monday, January 15, 2007

Python's super() Abused as a Hook

There has been some recent-ish discussion on the python-dev mailing list about "fixing" the super built-in, which is used to access attributes of an object with lookup rules on the superclass of a given class. This is used for different things and in different ways, but the most common usage seems to be as follows:

class Foo(Bar):
def action(self):
super(Foo, self).action()
self.actionCalledOnFooInstance = True

This causes a call to Foo().action() to call the action method of the next class in the Method Resolution Order. Now, Bar.action might exist, or maybe Bar inherits from Baz and Baz.action() will be called. The point is, you don't have to know. The typical pattern here is the that we are looking for the superclass of the same class we are within (Foo) and call the same method we're already in (action), which is a repetition some people want to fix.

I propose that super() is not broken at all, or even failing, but simply that we are misusing it where anothing idiom may be more appropriate. The more appropriate idiom might be hooks. Sometimes our function using super() should actually be calling a hook and other times it should be the hook. In the example above, we want something to happen after the regular action() method is called, so we redefine the entire action() method to call the original and then execute our one little line. We require all the overhead and issues with super() largely for varients of this common use case. Instead, consider if we wrote the following:

class Foo(Bar):
def hook_after_action(self):
self.actionCalledOnFooInstance = True

Do you see how much simpler that is? The requirement here is that either super(Foo, self).action would call hook_after_action if it exists (or there could be a default no-op version) or some mechanism outside of the action() method might handle it, perhaps wrapping it up on request or at definition. Maybe a standard hook format could even be a candidate for brining into the language.

Hooks are very valuable concepts that are not used enough. We can save ourselves a lot of trouble by using them. There is a lot more I could say about them, but this post was mostly about their relation to the many use cases of super.

PS - Some of this can be known to relate to the concept called "Aspect-Oriented Programm" which has very little weight in the Python world, because here its so easy to do that it doesn't deserve a name and is reduced to simply wrapping functions or having hooks.

Python on Windows and the PATH

Took me a few hours to track down a problem with importing win32com and getting "ImportError: DLL load failed: The specified module could not be found" which wasn't very clear. I doesn't even say what DLL it can't find!

Long story short, it boils down to python not being able to find the pywintypes25.dll, which is located in C:\Python24, but which is not in the PATH. Seems like having C:\Python25 added to PATH or some other solution would be a good idea. The problem wasn't even with the pywin32 package, which is what I expected and where I kept looking, but in the configuration and runtime environment of the python interpreter.

Sunday, January 07, 2007

PJE, I Have Little Time For What I Don't Prefer

Phillip J. Eby, I have a lot of respect for a lot of the things you right, including most of your recent posts. Dimwits refuse to learn, assholes yell at you for suggesting it, and good developers can acknowledge and embrace their faults and ignorance. No matter how much I learn I never want to think I have nothing left worth learning.

There are a lot of technologies and solutions I do not use. I'm sure all of them have their good points and their bad points, Zope included. However, I probably won't ever get to know much or anything about them. The time to familiarize myself in any valuable degree with Zope, Django, Turbogears, and mod_python is simply more than I have after using the solutions I actually apply to real usage.

Besides the things I can't find time to learn, even if I know they probably have really interesting aspects, there are definitely things I just won't learn or won't learn any more of. PHP is a good example, and many people know just how I feel about that. Yes, I might fit some of the descriptions PJE defined for people he would not hire. Asked about my worst experiences, I would likely bring up PHP and I don't believe I could have anything good to say about it. Is that ignorant of me, or is it just that bad? Maybe I just saw the limitations and before I learned real merits of the system, I moved on. Regardless, I've not locked myself into having no good answer for the interview question!

Never stop learning is a great rule to live by, but it doesn't mean you can't stop learning about particular things you deem invaluable to your precious time.
I write here about programming, how to program better, things I think are neat and are related to programming. I might write other things at my personal website.

I am happily employed by the excellent Caktus Group, located in beautiful and friendly Carrboro, NC, where I work with Python, Django, and Javascript.

Blog Archive