Efectos Especiales

I'm getting too much comment spam lately. It's not just the odd link anymore... somebody's spambots seem to be very much aware of my weblog (or at least the pycs.net part).

So, I decided to get rid of the comment option. I don't have time to think of a fancy solution, nor to keep track of all the incoming spam and delete it by hand. So I just got rid of the comment links in both this blog and TOTM.

A lot of valuable comments have been posted over time, and I don't want to lose them. So I wrote a little spider that downloaded the comments, got rid of most of the spam, and uploaded the cleaned-up versions to a new location. Weblog posts that used pycs for comments now point to this new location too.

So, from now on, if you have something interesting to say, or have questions, please mail me at the usual address. I don't like doing this, but I don't see a better solution right now.

This document was written a while ago, but I don't think I published it: Wax design goals. It's not complete yet; I expect it to be updated a few times in the near future.

I sincerely hope that the moment that this will be added to the language will be very, very far away...

[Update #1] I am usually far from enthusiastic about additions to the language, because I just consider it unnecessary cruft, and yet another small step away from the Python-the-small-language.

But this is different. Python with static typing will not be Python anymore. I don't mind that the few people who really need it will get this feature. I am more worried about those who don't need it but use it anyway just because they can. One comment to the Artima post pretty much said the same... if somebody who comes from Java (or C#, C++, Delphi, any statically typed language) is learning Python, and they discover that they can use type declarations, are they going to use them? Most likely they will. After all, they have learned that static typing is a Good Thing, and they will no longer be forced to use dynamic typing. So we will end up with lots of code with unnecessary type declarations. At that point, Python as we know it will have died.

I believe there is no such thing as "if you don't like it, don't use it and continue using Python like before". Programmers don't work in a vacuum. They read, use and maintain other people's code. Once this hits the fan, I will not be able to avoid static type declarations. (That will make me even grumpier than I am now. )

I still have hope that Guido will change his mind. Or maybe that he, after lots of pondering, will come up with a small, Pythonic solution that does what people want, but discourages abuse.

Still, I don't get it. Over time, Pythoneers seemed to have reached a consensus that Python programming was not about types, but what you can do with them. It's not important that x is a Foo; it's important that it supports the bar method. Now, Guido personally and single-handledly throws that notion out the door.

Steve Holden writes in c.l.py (about open source software in general):

This is, unfortunately, the road that Wax has been traveling. If I want more people than just me to use it, then I'll have to make sure that it's usable. (Well, duh. :-) It doesn't even have to support all, or most, of wxPython's controls. I think a stable, well-designed GUI with a limited number of controls is more useful than a GUI that tries to capture as many controls as possible but fails to reach maturity. ("Limited" here means that it should support enough widgets to build a professional-looking app. That includes the very basic controls like buttons, labels and dropdowns, but also notebooks, wxStyledTextCtrl, calendar, grid and listview.)

It's probably better to work towards 1.0 with a limited number of controls, and get a number of things straight, like properties, events, constructor arguments, sizers, etc. And solid documentation. *Then* more controls can be added, if necessary. (And whoever needs them before that time, can always dip into wxPython.) When or if that point is reached, we can worry about supporting more wxPython controls, more developers, etc.

Wax doesn't need to become *the* framework for Python GUI development. But it could become a reasonable alternative.

This site is interesting too. It shows an "atlas" of the universe; in this case, that means different maps for the nearest stars, galaxies, clusters, etc. The approach is a bit like Powers of 10, with the maps starting relatively close to our solar system, then zooming out more and more.

Animal Planet's Bird Technology. Interesting stuff... attach cameras to an eagle and see what flight looks like from a bird's point of view.

I saw Mercury this morning. The planet, that is, not the liquid metal, the car, the god, or the programming language.

I've been stargazing for over 20 years, but I've never seen Mercury before, at least not that I know of. Where I lived, the conditions simply were not favorable. After all, the planet doesn't rise very high above the horizon, and is only visible directly after sunset or directly before sunrise. In my area in the Netherlands, objects and smog always obscured the horizon. Here in rural Florida, things are a bit different, so when I woke up early this morning, and looked out the window, there it was, right next to Venus. (Of course, 15 minutes later, it was barely visible anymore, due to the sunlight.)

According to Skyglobe, the two planets are going to be even closer, reaching their closest conjunction around January 9th.

Enough about grants now. Let's discuss what I (we) can do with Wax. This is what I wanted to do (paraphrased from my proposal):

• Adding more controls, of course. (As long as wxPython keeps growing, this is probably a moving target.) I want to reach a stable release (call it 1.0) that should have all the controls necessary for building professional applications, using a clean, complete and easy-to-use API.

• Online documentation, in the form of a "book" that describes the important controls and common things to do with them. It should make it easy for beginners to just "jump in" and get started, rather than having to study source code or reference manuals. There should be plenty of examples.

• An editor that makes working with Wax easy. I now think of this as a Pythonic editor without all the fluff. Written in Wax itself.

• My proposal mentioned a GUI builder, but I'm not so sure about that anymore. There are existing programs that do this; maybe they can be made to work with Wax. This is something for later.

• Database bindings. Maybe in the form of database-aware objects (like Delphi has), maybe in some other form. Not sure yet. All this conforming to the Database API, of course.

• An improved website, that makes it easy for people to learn about Wax, look up documentation, release notes, etc.

• There should be a Sourceforge project, making it easy for people to contribute and report bugs, get the bleeding-edge version, etc. Maybe there should be a mailing list too. [I actually created a project for this a while ago, but I haven't done anything with it yet.]

• Installation should be made easier. For Windows, an executable could handle this. If nothing else, there should at least be a distutils script.

• More tools and examples, a comprehensive demo (maybe like wxPython's), auxiliary scripts.

That's a lot of work. First of all: is it worth it? If people aren't going to use it, then I am probably better off spending my time and energy elsewhere. It's a bit of a chicken-egg problem: people have little reason to use an immature Wax, but for Wax to become mature, people have to use it.

I basically have three options:

1. Do all the above, and spend a lot of time and energy on Wax. I don't know if I actually *have* that time and energy, considering I have a day job as well, but let's assume I do.

2. Spend as much time on Wax as I do now. Basically that means that it will be plodding along, probably never reaching a mature status.

3. Quit the project altogether.

For my *personal* use, #2 will be enough. I can just add controls when I need them, and will never have to worry about things I don't use.

However, a handful of people like Wax, and might benefit from #1. So I'm wondering if it will be worth it. Meeting all the goals of #1 is a lot of work; maintaining it might be even more. Once people actually start using Wax, I have to be super careful not to break backward compatibility. I'll have to make sure it works on the major systems (Windows, Linux, Mac OS X). I may have to work around bugs or warts in wxPython or wxWidgets. I may have to support multiple versions of wxPython. In other words, Wax will have to graduate from an interesting and useful toy project, to a professional framework for serious users. Is that really what I want? And will it have a significant user base? Or will there be too much competition? There are quite a few GUIs already, and Wax isn't the only one that builds on top of an existing framework, either.

Well, and then there's option #3. Not a very attractive option. But since I need a decent GUI framework anyway (that's why I started Wax in the first place), I could start a new project from scratch, or maybe contribute to an existing one.

Anyway, comments welcome. If you have an opinion on why Wax is cool, why it sucks, why you would (not) use it, what it needs, what's missing, etc, let me know.

(Followup to #667 and #668...)

I don't begrudge anybody their grants. All three proposals seem like useful projects that are worthy of funding.

However... not to be a pest, but I can't help but noticing that some of these are

• ongoing projects
• unclear about what the money is used for
• unclear about the user base that will benefit from it

...which were reasons for the committee to reject other grants (not just mine), but apparently the same criteria do not hold for all proposals.

If there is another call for grant proposals next year, I don't think I'm going to apply again. If the committee can't even be bothered to read the proposal and come up with an appropriate rejection note, I don't see why I would waste my time.

This kind of thinking seems to be gathering momentum...

This is *why* it is gaining momentum.

(from Kyle Cordes)