How To Stop Me From Buying An iPod Touch

So I've been looking at the new line of iPods and thinking about how much I wanted an iPhone without the phone, so the iPod Touch seemed to be exactly what I wanted. Thankfully, Morgan Webb pointed me to this story about why I might be reconsidering. Now, I run both Windows and Linux. My wife is the one in the household who refuses to run Windows at all, how about that? On both operating systems I already have players that can use the old iPod lines. I use WinAmp and Amarok, although I am anxious for Amarok on Windows to be stable enough to move to. Sorry, Nullsoft! Where am I left now? I guess I need to look at my options, and I'm not really excited over the UI itself on the Touch, but the hardware. Do Nokia Internet Tablets include an MP3 player with decent battery time? I could import a miniOne from China. Thank you eastern friends!

How quickly can Apple break their high horse's legs?

How to Confuse _ and locals()["_[1]"]

So, after posting about the exception raising list comprehensions, I got this:

Kevin has left a new comment on your post "How to Add Memory Leaks to Python":

Doesn't '_' only exist in the interactive interpreter?

Kevin has a misunderstanding here in that there is a huge difference between the expressions _ and the locals()["_[1]"]. You might spot why they are so different, or you might not. The second, the one from the list comprehension, is unable to be accessed by name directly. You can only get at it via the locals() and globals() functions, depending on your scope (locals() always works right after the LC in question, though). The name is intentially something that, if tried to resolve as an actual name in the scope, won't find the object in question. Python will look for _ and then do a subscript lookup on key 1 on it. This is completely different than actually looking up the name _[1] in the dictionary where names are stored and grabbing up the value its bound to.

So, Kevin, your question can be answered in that its irrelevant, because we aren't dealing with _ at all. Also, open your profile so I can respond to you directly, next time.

How to Pretend Zope Doesn't Exist

I'm doing my best to ignore that I just read Well-kept secrets of Zope, which lists all sorts of things I'm interested in seeing developed and how Zope did it. Zope is our Simpson's to South Park's Python community. All of this ORM wild fire and debates about unicode support and web frameworks seem really petty when someone reminds us that Zope, which most of us never really look at, has been doing some of these things for over a ten years. That's practically a decade in software time!

Will I settle back into a comfortable hole in the ground, cover my years, and chant "There's no such thing as Zope" or am I going to bite some pride and surround myself with Zope? The first talk for a CharPy meeting is going to be on Zope, and I'm going to ask a lot of questions about why it gets ignored and how someone really familiar with Python can get into Zope so late into the game. Now, I am not planning to drop everything else. I still think CouchDB has some interesting ideas that I'm pretty sure aren't part of ZODB. I'm also a huge Twisted fan, where it applies. We've had some segmenting problems in Python with Zope and non-Zope, Twisted and non-Twisted and, more recently, Django and non-Django. We seem to be gaining a habit of frameworks that gain a really large following and are really known to those who don't use them, who continually ignore the developments. If Zope and Twisted played together better, both in code and community, would Django ever have even surfaced to fill the gap? Would Rails have been irrelevant?

We need to build some bridges, so who wants to shake hands?


Technorati Tags: python, zope

How to Add Memory Leaks to Python

One of our greatest bragging rights is the lack of memory management in our Python code and the wonder of garbage collection, so when we find a way to get a memory leak in Python, it should be made well known. I don't know if this is already known, or not. In actuality, these situations are known as reference leaks, sometimes, and they are cases where we forget to remove a reference to an object we don't want to keep around anymore. The following session will cause this problem.


Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
... for i in xrange(100):
... yield i
... raise Exception("oh no!")
...
>>> [x for x in f()]
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4, in f
Exception: oh no!
>>> globals()['_[1]']
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99]
>>>


Now, there is a global that will sit around referencing a potentially very large list and we won't be aware of it. However, it will be overwritten if another list comprehension is run in the same scope, which will be removed if the new LC is successful, and if we do our LCs in functions, the local will be cleaned up on return or raise. Of course, you can always just pass a generator expression to list() and avoid the problem entirely.

Just keep an eye out, if you build global constants with list comprehensions.

Python, Concurrency, and My Two Cents Today

This is not the first and it will not be the last that I write about the state of concurrency in Python, comment about some debate going on in the community, and outline what I think we need to solve any apparent problems and capitalize on what a lot of us think is the future of software development. Anyone following the Python blogs is bound to have caught wind of the Guido-Eckle debate about what Python 3.0 has become, compared to what it could have been. This was followed immediately by an open letter from Juergen of SnapLogic about the GIL. I feel sure this has all happened again and that all parties involved are just playing some recorded macros.

The most compelling case we have right now against the arguments to remove the GIL are two. Firstly, it was already done! A branch of Python removed the GIL many years ago and actually found a two core/cpu system would run the same code slower, due to all the locking involved to protect mutable structures. So, while people continually say that the GIL needs to be removed, gets in their way, and generally is a wart on Python, we need to remind them that its been done and it was a bad idea. The GIL is not being kept in as a product of laziness.

Secondly, threading is not the definitive answer to concurrency needs! This is a really important one, because one of the areas that I always see the Python community strive at is finding the right way to replace the popular way. Threads are very popular in a lot of circles, but there is a huge consensus that they are simply a misrepresented de facto with little in the way of justifying the use they see. The Java world, in particular, seems to think that throwing threads at a problem can solve it. What we have to realize is how many problems are caused by threading and if they outweigh the benefits. A lot of us can't see those benefits through all that cost, so we've looked in other places for concurrency, and we've found it. In some ways, the GIL acts as a deterrent to force us into finding a better way. I, for one, am all for keeping it around just for that reason.

Where can I really go with this? Not far. I could ramble and rant about processes being better concurrency primitives than threads, but I don't feel this is the time or the place. But, please, can we stop asking for the GIL to be removed? No on is going to listen to that plea. The issue is going to come up again, and that is absolutely a promise. We're going to see this again and again, until we have something solid, standard, and powerful enough to distract the thread lovers from the GIL issues. I don't know what that solution is, but we need to figure it out soon. Guido is right, of course, and this is a library issue, not a language issue. However, we can't deny what value this library issue has for the language, and a little encouragement or name dropping on his part might do well to push a good answer to the forefront. Eventually, something needs to get to the point that we can bring it into the standard library and say "This is how you do concurrency in Python."

Who wants to answer the great question? Step up.


Technorati Tags: python, threading, concurrency

How to Shop for a Portable Device

What do I want? Do I even need a phone? When the iPhone came out, my first reaction was wishing it wasn't a phone. If I want a touch screen in my pocket, shouldn't I safe money and open my options with a Nokia Internet Tablet? The iPod Touch and the iPhone will be open, eventually. They can be coerced into running new things, already. The Nokia has a huge library of software, and can be made to run linux with lots of apps I already use. The price is undeniably better, of course.

Everything says "Don't get the expensive Apple device," and yet, I want to buy it. I even want the phone model, when I don't want a phone. What great marketting.

If I could find any decently open e-paper device, I'd jump on it before anything else.

How to Exploit All of You For Traffic

People go through a few different stages of programming Python, and one of the last is learning to optimize well and without sacrificing the quality of the code. When a piece of code is bottlenecking, it comes time to look at how you can really turn a turtle into a hare. Or, should that be the other way around?

I want to showcase ways this transformation is possible so I'm going to make a call for anyone to submit code that needs optimized. The next post in this series will show how the code was optimized, what techniques might have been tried and would have failed, and maybe some tips about why the changes worked. There will also be a sample of unoptimized code at the end, with the challenge for improvements to be sent in. From there, if the series has interest, it will continue and maybe evolve.

Send in samples of code you think could be faster. They can be real world or fake, as long as they are realistic. It doesn't matter how poorly written they are, but we need to know what it does. It needs to actually work. The best submissions will be a single function and a docstring that tells me what it can be called with and what it should be expected to do. Things that can unittest well and don't rely on things from the outside are best.

So, impress me, everyone, with the worst code you've got.

How to Improve on CouchDB

The CouchDB project has been getting a lot of talk lately, all over the blogosphere and in particular in Python circles, who like JSON and REST and are excited at the new move to them from XML. I really liked what I saw. I also knew I could have liked it a lot more.

You know something interesting is happening when someone with my anti-XML track record says the following: XML should not have been dropped from CouchDB.

I can clarify and reaffirm that I am not crazy by saying that this does not mean JSON should not have been added, but that it should not have replaced anything. In other words, both are fine. While we're at it, why does it matter what format the "document" is in? Be it an XML document, a JSON serialization, or a photo, anything could benefit from the basic architecture of CouchDB.

Looking into the details, I'm disappointed that the distribution model is just smarter replication. Something like this really should be able to do sharding out of the box, with its really unique identifiers and revisioned nature.

Can CouchDB satisfy my requriements or do I need to write SofaCouchDB?

Charlotte Python Group: First Meeting

We had the first meeting of CharPy, the Charlotte Python Group, this morning at Nova cafe downtown. There were only three of us, but most user groups only start with a handful of people, and I'm looking forward to how it grows. We're going to keep this going on the 1st and 3rd Fridays, and anyone else is welcome to join us.

Brain Dump 20070904

When things build up and I haven't posted, what to write about is a difficult thing to decide. This is a dump of recent or queued topics just to get them out of the way for new things.

What's Up With This Hip Cat:

• Looks like we're getting Charlotte Python Group (CharPy) together, and hopefully having some coffee one morning this week. Let me know if you're interested!
• I'm stretching my legs at a bigger desk in the home office.
• I'm trying to consider how to approach an open Python position I found in this area versus a possibility with someone I had a great time working with in the past versus moving to Australia down the road.
• Knitt and Oasis are great little indie games. I wish I could have taken part in PyWeek, but I am so busy! Pyglet looks interesting these days.
• Took on a tight deadline project at the same time as work on Python Magazine ramped up, because I'm just that willing to bend over for money.

I know I don't write enough. I have to write my column for the October issue of Python Magazine and maybe that will jog something in my brain.