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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED] > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
