[python-win32] python3 and extended mapi

Christian K. ckkart at hoc.net
Tue Jun 10 03:40:02 CEST 2014


Am 09.06.14 16:00, schrieb Paul_Koning at Dell.com:
>
> On Jun 9, 2014, at 2:53 PM, Christian K. <ckkart at hoc.net> wrote:
>
>> <Paul_Koning <at> Dell.com> writes:
>>
>>>
>>>
>>> On Jun 9, 2014, at 9:07 AM, Christian K. <ckkart <at> hoc.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was very pleased to see that retrieving properties of a MAPI object yields
>>>> either a <str> or <bytes> type depending on whether the _A or _W property
>>>> was queried …
>>>
>>> Really?  That seems strange.  As I recall, the *_W APIs are “wide
>> character” ones.  So in Python 3, they
>>> should both map to <str> type.  <bytes> applies only to non-text data.
>>
>> At least for text properties like e.g. PR_SUBJECT_A / _W the former returns
>> a mbcs encoded "string", i.e. of bytes type and the latter a 2-byte unicode
>> string. Binary properties are always returned as bytes in contrast to
>> earlier when using pyrhon2.
>
> Yes, “bytes” for binary values is clearly correct.  But MBCS and “2 byte Unicode” (more accurately called either UCS-2 or UCS-2 BMP subset, not sure which) are both text strings.  The different encoding in the API doesn’t mean they should be different datatypes in Python 3; both cases are properly mapped to “str”.

No, this is not what I am seeing. MBCS encoded properties, i.e. those 
terminating with _A are mapped to 'bytes' and the _W ones to 'str' which 
is consistent with the handling of unicode and encoded information in 
python3. And this is great indeed because having to distinguish between 
strings which can be encoded or not while having the same type is really 
painful.

Christian





More information about the python-win32 mailing list