[Python-3000] struni and the Apple four-character-codes

[Ronald Oussoren]

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 PyMac_GetOSType(),
> 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