Improving Python

Steve Holden steve at
Mon Dec 27 13:57:34 CET 2004

Aahz wrote:

> In article <mailman.8453.1104070799.5135.python-list at>,
> Fredrik Lundh <fredrik at> wrote:
>>func(*arg) instead of apply() is a step back -- it hides the fact
>>that functions are objects, and it confuses the heck out of both
>>C/C++ programmers and Python programmers that understand the "def
>>func(*arg)" form, because it looks like something it isn't (there's a
>>false symmetry between the call-form and the def-form).
> For me, it works the other way around, but I can see how you perceive it
> that way.
>>and I still do enough 1.5.2-programming to use "x = x + y"; when I find
>>myself in a situation where my code would benefit a lot from being able
>>to write "x += y" instead, I go back and fix the design.
> Okay, it wasn't clear in your original post that you're still stuck with
> 1.5.2.  That makes a huge difference in the convenience of newer
> features.
I haven't corresponded specifically with Fredrik about this, bit I get 
the impression he *chooses* to continue to produce 1.5.2-compatible 
products. I for one, having suffered at the hands of modules that 
*claim* 1.5.2 compatibility (and then screw you by using dict()!), 
appreciate the time he takes to do so.

A summary of how to maintain such compatibility might make Python apps 
more accessible - how many of us can say that our code would run on a 
Red Hat 7 system any more? The sad thing is that it's often fairly 
trivial changes that remove backwards-compatibility.
>>string methods are nice, but nothing groundbreaking, and their niceness
>>is almost entirely offset by the horrid "".join(seq) construct that
>>keeps popping up when people take the "the string module is deprecated"
>>yada yada too seriously. and what do the python-devers do? they add a
>>"sum" built-in, but no "join"? hello?
Well, I guess we have to accept that not every change to the language is 
going to be well-thought-out and completely desirable.
> While I'm in complete agreement about the "".join() construct on the
> basis of looks, I have come to appreciate the fact that I *never* mess up
> the order of arguments any more.

Personally that's one of the changes I managed to take in my stride, and 
  I've never really felt it was a biggie. Maybe my code is just so ugly 
that a little extra ugliness isn't noticeable?

horses-for-courses-ly y'rs  - steve
Steve Holden     
Python Web Programming
Holden Web LLC      +1 703 861 4237  +1 800 494 3119

More information about the Python-list mailing list