[Python-3000] struni and the Apple four-character-codes (original) (raw)

Ronald Oussoren ronaldoussoren at mac.com
Fri Jul 27 08:11:28 CEST 2007

On 27 Jul, 2007, at 5:38, Jeffrey Yasskin wrote:

I've sent the patch as http://python.org/sf/1761465 using Guido's suggestion of using bytes, but I do philosophically prefer Talin's and Ronald's suggestions.

On 7/25/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote: I've CC-ed Jack Jansen as he has maintained the Mac libraries for ages (from way before OS9 was shiny and new). Did you mean to add him to this thread?

Yes, but I obviously failed to actually add this address to the CC
list :-(.

On Wednesday, July 25, 2007, at 07:18AM, "Jeffrey Yasskin" <jyasskin at gmail.com_ _> wrote: > 5) Make a new hashable class for these codes which converts them to >and from ints and bytes and becomes the general argument type for the >apple platform interface. [Cleanest, but lots of work that I'm not >volunteering to do] A 6th option is a subclass of int. It's constructor would accept a string containing the 4CC and the repr/str method would return the string representation of the code. IMHO this is the cleanest representation of 4CCs in Python because those codes are basicy a "neat" way to enter integer literals in C. Naïve question: How does that differ from option (5)? Just the isinstance() behavior?

That's the only change, but it is an important one. To reiterate: 4- character-codes in C are numeric literals and it would be best if
Python reflected that fact to avoid surprises. 4-character-codes are
definitely not arrays of bytes.

One example of an API that returns a dictionary where some keys refer
to values that are commonly encoded using 4-character-codes is - [NSFileManager fileAttributesAtPath:traverseLink].

I said this would take a lot of work because I think the new type needs to be implemented in C to be returned from PyMacGetOSType(), and it seemed like a bigger API change than just switching to bytes, but it turns out that switching to bytes isn't particularly trivial either when you have to cast for every use in a dict, so maybe the new type would be easier.

The new type would be easier and the API change isn't too bad. I don't
think you'd have to implement this type in C, there just needs to be a
hook to tell the C code about this type.

This would also solve a problem that PyObjC users sometimes run into: Several C/Objective-C APIs return a dictionary where one of the values is an integer and where one would commonly use 4CCs to write down literals. This currently causes unexpected failures but would do the right thing with this option. I don't think that option (6) by itself solves with that particular problem. If you call str() on one of those ints, you'd just get a number, which is different from what would happen if you call str() on the 4CC type. It might help though by handling comparisons correctly.

That's what I meant by "the right thing": code would just work except
for not printing a nice human-readable value. As you don't have to do
that a lot anyway that's not really a problem.

Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/python-3000/attachments/20070727/56c25928/attachment.bin

More information about the Python-3000 mailing list