On Jun 14, 2014, at 10:10 AM, Christian K. wrote:
>>> Dell.com> writes:
>>
I would only want/expect to see “bytes” types when the values in question
>>> are binary data streams, or
unknown format. But anytime we’re dealing with text strings, the Python 3
>>> approach is that the Py
Dell.com> writes:
I would only want/expect to see “bytes” types when the values in question
are binary data streams, or
unknown format. But anytime we’re dealing with text strings, the Python 3
approach is that the Python
code sees “str” type, and questions of encoding have been handled
Christian K. hoc.net> writes:
>
> Dell.com> writes:
> > I would only want/expect to see “bytes” types when the values in question
> are binary data streams, or
> > unknown format. But anytime we’re dealing with text strings, the Python 3
> approach is that the Python
> > code sees “str” type
Mark Hammond gmail.com> writes:
>
> It would be great if you could open a bug at sourceforge...
Done.
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32
Dell.com> writes:
>
>
> On Jun 9, 2014, at 9:40 PM, Christian K. hoc.net> wrote:
>
> > Am 09.06.14 16:00, schrieb Paul_Koning Dell.com:
> >>
> >> On Jun 9, 2014, at 2:53 PM, Christian K. hoc.net> wrote:
> >>
> >>> Dell.com> writes:
> >>>
>
>
> On Jun 9, 2014, at 9:07 A
paul_kon...@dell.com wrote:
> Perhaps I’m missing something.
I'm not sure you're missing anything. You're simply describing another
implementation choice that could have been made. Both your scheme and
the actual scheme have their merits.
> I’m used to Windows API calls that come in a foo_A an
On Jun 9, 2014, at 9:40 PM, Christian K. wrote:
> Am 09.06.14 16:00, schrieb paul_kon...@dell.com:
>>
>> On Jun 9, 2014, at 2:53 PM, Christian K. wrote:
>>
>>> Dell.com> writes:
>>>
On Jun 9, 2014, at 9:07 AM, Christian K. hoc.net> wrote:
> Hi,
>
> I was
It would be great if you could open a bug at sourceforge...
Mark
On 9/06/2014 11:07 PM, Christian K. wrote:
Hi,
I was very pleased to see that retrieving properties of a MAPI object yields
either a or type depending on whether the _A or _W property
was queried and entryids are always returne
Am 09.06.14 16:00, schrieb paul_kon...@dell.com:
On Jun 9, 2014, at 2:53 PM, Christian K. wrote:
Dell.com> writes:
On Jun 9, 2014, at 9:07 AM, Christian K. hoc.net> wrote:
Hi,
I was very pleased to see that retrieving properties of a MAPI object yields
either a or type depending on
On Jun 9, 2014, at 2:53 PM, Christian K. wrote:
> Dell.com> writes:
>
>>
>>
>> On Jun 9, 2014, at 9:07 AM, Christian K. hoc.net> wrote:
>>
>>> Hi,
>>>
>>> I was very pleased to see that retrieving properties of a MAPI object yields
>>> either a or type depending on whether the _A or _W
Dell.com> writes:
>
>
> On Jun 9, 2014, at 9:07 AM, Christian K. hoc.net> wrote:
>
> > Hi,
> >
> > I was very pleased to see that retrieving properties of a MAPI object yields
> > either a or type depending on whether the _A or _W property
> > was queried …
>
> Really? That seems strang
On Jun 9, 2014, at 9:07 AM, Christian K. wrote:
> Hi,
>
> I was very pleased to see that retrieving properties of a MAPI object yields
> either a or type depending on whether the _A or _W property
> was queried …
Really? That seems strange. As I recall, the *_W APIs are “wide character”
o
Hi,
I was very pleased to see that retrieving properties of a MAPI object yields
either a or type depending on whether the _A or _W property
was queried and entryids are always returned as bytes types. Very nice! This
makes a lot of bin2str2bin conversion and encoding/decoding code obsolete.
Nev
13 matches
Mail list logo
