[Pythonmac-SIG] NSTableView and NSOutlineView backgrounds

[Bob Ippolito]

On Tuesday, Oct 14, 2003, at 14:38 America/New_York, Drew McCormack 
wrote:

>> Along the same lines, ObjC doesn't have a short way to say anything 
>> (no operators).  Probably my favorite feature of Python are strings, 
>> lists and dicts, with all the great __setitem__/__getitem__ stuff to 
>> go with it.  In ObjC, a+b never means anything useful, unless a and b 
>> are primitive C types.. that's obnoxious, because you'd have to say 
>> a.add_(b) or something like that... Imagine writing an equation like 
>> that.
> Well, I have a different view of operator overloading. I think it is 
> generally unnecessary, and can even have negative effects. The problem 
> is, a lot of people don't know what is happening behind the scenes. If 
> you have a matrix expression in C++ like this
>
> a = b * c + d
>
> you are creating two temporary objects. This has lead to the dismal 
> performance of C++ in number crunching in the past.
> At least in Objective-C, it is explicit:

Yes, for doing math using custom types and creating temporary objects 
is kind of stupid.  What you really want for that kind of math is to 
describe an operation and then apply the operation to a set of objects 
in such a way that doesn't create a bunch of useless temporary sludge.  
I'm sure there's some languages out there that do stuff like this 
(implicitly or explicitly) but I've never seen one that's mainstream.  
What I really meant were things like descriptors, sequences, slices, 
dicts, callable objects, etc.  These are all generally very elegant in 
Python (once you get over __this__).

>>  Sure, in ObjC you can use int, long, float, double.. but what about 
>> equivalents to Python's long or complex?
> ??
> typedef struct _Complex {
> 	double real, imag;
> } Complex;

<math.h>'s abs() can't take a _Complex.  It's just not treated as 
nicely as the my-processor-understands-these-natively number types by 
the standard library.  You can't add two _Complex with a + either.

> Where I prefer Obj-C/Cocoa:
> Possibility of static typing (makes large programs more readable, and 
> catches a few bugs at compile time)
> Design of libraries. Cocoa is beautifully designed and stable. I have 
> the feeling python's libs have evolved in a less stable way. With each 
> new release of python, things get replaced, indicating they weren't 
> that well done the first time round.

Explicit static typing is ok, sometimes, I just don't like to have to 
do it and I don't like to explicitly cast things all the time.  Usually 
the only time I want to do it is for performance reasons (static typing 
of non-objects).  What *really* bugs me about static typing in 
languages like C# is that you have to explicitly cast things from 
object to another type, even though it's an absolutely worthless 
convention for catching legitimately mismatched types at compile time.  
This sort of thing happens ALL the time when you're working with data 
structures like hash tables.  Ideally static typing should be more like 
it is in ML.

Cocoa is well designed and stable, but it's a GUI framework.  Python 
doesn't really have one of those that doesn't inherit the warts from 
whichever underlying C/C++ library it's talking to.  The exception, of 
course, is PyObjC which talks to Cocoa and doesn't come standard with 
very many warts.

Apple has made good frameworks and bad frameworks (or at least, they 
release incomplete ones that a lot of people are using).  The 
Authorization framework for example is a chore to use (in the way that 
they show you how to use it, at least) and allows for a few 
opportunities to hijack a file that's about to be given suid root, 
although they are difficult to pull off.  Their installation framework 
kinda sucks, and often gives /Library g+w admin, which means that you 
can put arbitrary will-run-as-root-next-time-you-boot code in 
/Library/StartupItems as an administrator... This is a pretty big 
(read: almost Microsoft-like) security hole and will require changes to 
the frameworks (both implementation and interface) that they just 
haven't done yet.  Personally, I think /Library/StartupItems scripts 
should be run as whichever user owns the bundle, which would solve that 
problem even if /Library had junked permissions, but would break a lot 
of existing software that needs startup items.  A workaround for this 
is pretty easy though, on startup it could warn the user that "Warning: 
  The following startup items wish to be run with full permissions but 
have not yet been granted access.  If one of these startup items has 
malicious code, and you run it, you're screwed.  Click this button if 
you would like to authorize any of them.  Note that authorization 
requires an administrator login and password."

That said, Apple code probably gets more eyes on it and more stringent 
review Python code.  A lot of Python code I've seen in the wild looks 
like first-thing-that-worked prototypes, and this includes code in the 
standard library.  I generally try and look at the source for Python 
libraries before I try and use them for anything.  If the 
implementation or interface sucks, I'll probably find another one that 
does the same thing, try and help fix it, or write my own (either full 
replacement, or subset of it that's designed to do what I need).  I 
can't do that with (some) Apple frameworks, although in many cases I'd 
like to.

-bob