Skip to main content

Python: PyCon 2005 random thoughts

Some people have asked me to provide some comments on PyCon 2005. Here is an informal collection of impressions and opinions. I won't cover the Web topics because I've already done that.

Alex Martelli's talks are a joy. I especially liked his talk on 'Descriptors, Decorators, Metaclasses: Python's "Black Magic"'. I just wish he had more time. 25 minutes is simply not enough time to understand the subjects he is trying to convey unless you already understand them.

PyPy is definitely not what I thought it was. Apparently, it's about type inference. I thought it was an attempt to rewrite the front-end of the Python interpreter in Python so that the front-end could be shared among all the versions of Python. If this were the cases, the front-end could be distributed as .pyc's, and all the versions of Python would only need to write VM's to interpret the .pyc's. :-/

wxPython is a pain to use. PythonCard is a wrapper around wxPython that makes it a joy to use. PythonCard is obviously not as mature as a lot of widget toolkits, as I can see obvious deficiencies (e.g. more sophisticated layout strategies). However, it is quite impressive.

Schevo is interesting. It's a GUI for object databases.

"Dabo, the 3-tier Database Application Framework" is a database-neutral, GUI-neutral RDBMS GUI. The author complained about wxPython a lot. The author mentioned that 80% of his effort was spent working around wxPython. I asked why he didn't use PythonCard. He said he wanted to remain GUI neutral. The whole thing looked like a bit of a waste of time :-/

Durus is a trimmed down version of Zope's object database. Having seen Schevo, I can see that object databases can make a certain set of database problems a bit simpler to solve.

Soap box warning:
However, I just don't see why people have to spend so much time trying to solve problems that were already solved in the 70's. Why does everyone hate SQL? I think SQL's the best thing to happen to computer science in the last 30 years! Here are things that RDBMS's do that object databases have a hard time with (although some do succeed with some of these points):
  • Cluster.
  • Atomic transactions that work even if the power chord is pulled at an inopportune moment.
  • Query extremely large data sets without transmitting all of the data to the client. Furthermore, the RDBMS can execute the query one hard drive block at a time without trying to bring the whole table into memory.
  • View the data in ways it wasn't meant to be viewed, i.e. do joins on arbitrary fields.
Concerning iterators and generators, I took away these two points:
  1. Anytime the loop logic gets complicated, write a generator so that the loop logic can be reused.
  2. Use the itertools module. It's blazingly fast and convenient.
"Sequential Code in an Event-Driven World" was basically "generators are cool."

"Python for Series 60" was impressive. I want one, but Sprint doesn't have them. Bang for buck, it's hard to beat Symbian phones.

Comments

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and jabber.org. Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p