Re: [PyOpenGL-Devel] Python 3- strings or bytes interface

[Mike C. F. <mcf...@vr...>]

On 12-04-05 09:32 AM, Rob Reilink wrote:
> Hi,
>
> The suggestion of checking for unicode objects makes sense to me -- 
> although I would suggest to use ascii encoding, unless someone could 
> point me to a document that explicitly states what encoding is used 
> for the GLubyte* arguments. Since ascii encoding raises an error upon 
> encountering bytes > 127, I think that is the safest bet unless we are 
> sure what encoding is actually used.
ASCII is fine for every use of GLchar* that I *know* about.  The problem 
is finding any corner cases (now or in the future) where some obscure 
extension uses GLchar* to mean an 8-bit string.  That said, I'd be fine, 
for now, making GLchar point use ASCII encoding on Unicode ingest (it 
just blows up now, after all), and requiring users to explicitly encode 
if they want to use an 8-bit-clean GLchar * API.
> As far as I know (but my OpenGL knowledge is limited) glGetString is 
> the only function that actually returns a string. So we could add a 
> glGetUnicode or glGetStr or glGetPyStr (suggestions for appropriate 
> name welcome) that always returns a 'str' -- 8 bit on Py2 and unicode 
> on Py3. And leave glGetString return a bytes object for the reasons 
> mentioned. This new function could then be used in the extensions 
> module; I think this way many of the as_8_bit calls can be avoided 
> because then the extensions module would just use the Python native 
> string type.
I'm pretty sure there's more than that, e.g. glGetActiveUniform.  My 
current preference is that we will *always* return 8-bit from API calls 
that are documented to return 8-bit values, while allowing ingest of 
unicode values IFF they are ASCII compatible (comments on my blog 
suggest this is the path Python 3.3 is taking anyway).  On output, I 
really don't want to mess up the API with lots of extra entry points 
which are non-standard and need to be documented, maintained, etc.

> I'd be happy to go and implement this solution, if you can point me to 
> the appropriate place to put the code. It will probably be a bit of 
> puzzling how to write it such that it works properly when transformed 
> by the 2to3 tool :-)
I'm fine with implementing it.  The generator knows the type of all 
variables, so it can generate wrapper-generating code to do the 
conversions (i.e. apply a decorator that wraps the raw operations on 
generation).  The wrappers will need to be written such that they are 
fairly fast, but that shouldn't be a huge problem.  The as_8_bit call 
survives 2to3 AFAIK.

Enjoy,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com