[Python-Dev] ParseTuple question

[Ulrich Eckhardt]

[sorry, dropped one pair of mails off the list, hence also the overquoting]

On Sunday 04 January 2009 01:07:08 Mark Hammond wrote:
> > > On 'normal' windows you generally would need to use
> > > WideCharToMultiByte() to get a 'char *' version of your wchar
> > > string but I expect you already know that, so I doubt I understand
> > > the question...
> >
> > Actually, I want the exact opposite.
>
> I'm not sure you can get it though :)  Unless you can change Python itself,
> you will be forced to convert filenames etc back and forward from wide to
> narrow strings.  This should roundtrip OK for all character in the current
> code set.
>
> > 'char' strings under CE are mostly useless, in particular for
> > filenames. Actually, they are useless under MS Windows in general,
> > at least for the versions supported by Python 2.6/3.0, they all use
> > UTF-16, only the desktop variants still have backward compatibility
> > code to use 'char' strings, though with restricted functionality.
>
> Exactly - but for python 2.6, we are still somewhat forced to use that
> 'char *' API in many cases.  If the API didn't offer the automatic unicode
> conversion, we would most likely have needed to implement it ourselves.
>
> > So, point is that I need a UTF-16 string in a function that might
> > get either a string or a Unicode string. Preferably, I'd like to take
> > the way that poses least resistance, so which one would you suggest?
>
> I'm not with you still: if a Python implemented function accepts either
> string or unicode, then your utf16 string is perfect - its already unicode.
> On the other hand, I thought you were faced with a Python function which,
> as currently implemented, only accepts whatever the 's' format string
> accepts. Such a function only accepts real PyString objects, so attempts at
> passing it unicode will be futile.  Obviously you could modify it to accept
> a unicode, but clearly that would also mean adjusting everything that uses
> the existing 'char *', which may end up fanning out to much more than you
> expect.
>
> If I'm still misunderstanding, can you be more specific about the exact
> problem (ie, the exact function you are referring to, and how you intend
> calling it)?

trunk/_fileio.c/fileio_init()

Let's leave aside that you can also pass a filedescriptor, that function 
either takes a string or a Unicode string as first parameter. Now, under CE, 
I always need a 'wchar_t*' in order to open a file, how would I get at that 
easiest?

My approach now is to simply use "O" as format specifier for the filename and 
then take a look at the object's type. If it is a char-string, I have to 
convert (under CE) or call the char-API (desktop MS Windows), if it is a 
Unicode string, I can use it as it is.

Uli