Re: Python 3- strings or bytes interface
Rob Reilink <[email protected]> Thu, 5 Apr 2012 15:32:03 +0200
| Newsgroups | gmane.comp.python.opengl.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============8311410698500747043== Content-Type: multipart/alternative; boundary=Apple-Mail-23-990721308 --Apple-Mail-23-990721308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. 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'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 :-) Rob --------------------------------------------- Rob Reilink, M.Sc Science Applied phone: +31 6 187 26562 e-mail: [email protected] --------------------------------------------- Op 4 apr 2012, om 17:44 heeft Mike C. Fletcher het volgende geschreven: > On 12-04-04 07:23 AM, Rob Reilink wrote: >> Hi, >>=20 >> I've noticed that under Python3, PyOpenGL inconsistently expects = 'str'=20 >> and 'bytes' objects as function arguments. For some functions, I'd=20 >> expect to use 'str' while in the current implementation 'bytes' is = used. >>=20 >> E.g. in glGetUniformlocation, the name of the uniform is to be=20 >> specified as a 'bytes' object, while I would expect to use 'str' = since=20 >> it is a name. Also, shaders.compileShader takes a 'str' for the = shader=20 >> code >>=20 >> Similarly, extensions.hasGLExtension() expects a 'str' object for the=20= >> extension name, but extension.AVAILABLE_GL_EXTENSIONS is a list of=20 >> 'bytes'. >>=20 >> Of course, for arguments dealing with binary data (e.g. = glTexImage2D),=20 >> a 'bytes' object is to be used. >>=20 >> Apart from the actual implementation, has there been any thought on=20= >> how to expose things like uniform names to the user? > My first reaction would be to do this: >=20 > if isinstance( arg, unicode): > arg =3D arg.encode( 'latin-1' ) >=20 > in the wrapper (the as_8_bit() hack has been added to the extensions=20= > module, for instance), that is, for each argument which is current = str,=20 > make the argument capable of accepting a unicode argument... as for=20 > producing them... I'm hesitant to convert the 8-bit values (which is=20= > internally what OpenGL is specifying; GLchar * is an 8-bit value) to=20= > unicode arbitrarily, as now code that uses formal, correct, = byte-strings=20 > is going to crash when it tries to interact with the generated unicode=20= > values. >=20 > Everything in OpenGL is binary data. Everything has an expressly = defined=20 > binary representation, and that includes byte-strings. Anything I do=20= > here to paper over the difference is, I expect, going to come back to=20= > byte us in the future. Someone is going to do a glGetActiveUniform() = in=20 > my_unicode_shader and have it blow up on a unicode/bytes disagreement = if=20 > I convert on return, or is going to do glGetActiveUniform() in=20 > my_bytes_shader if I don't, but I expect that the number of problems=20= > with glGetUniform( 'myuniform' ) will be substantial. >=20 > Basically I don't have a good solution. Either we create an API=20 > inconsistency between Python 2 and Python 3 (returning "str" in both,=20= > though they are different types), or we make Python 3 users explicitly=20= > deal with the return-type of the GLchar* calls and/or use byte-strings=20= > everywhere. >=20 > Enjoy, > Mike >=20 > --=20 > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com >=20 >=20 > = --------------------------------------------------------------------------= ---- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second=20 > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel --Apple-Mail-23-990721308 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div>Hi,</div><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div>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 = :-)</div><div><br></div><div>Rob</div><div><br></div><div><div><br><div> <span class=3D"Apple-style-span" style=3D"border-collapse: separate; = color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: = 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: = normal; font-weight: normal; letter-spacing: normal; line-height: = normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; = "><div>---------------------------------------------<br>Rob Reilink, = M.Sc<br>Science Applied</div><div><br>phone: +31 6 187 = 26562<br>e-mail: <a = href=3D"mailto:[email protected]">[email protected]<= /a><br>---------------------------------------------</div><div><br></div><= /div></span><br class=3D"Apple-interchange-newline"></span><br = class=3D"Apple-interchange-newline"> </div> <br><div><div>Op 4 apr 2012, om 17:44 heeft Mike C. Fletcher het = volgende geschreven:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div>On = 12-04-04 07:23 AM, Rob Reilink wrote:<br><blockquote = type=3D"cite">Hi,<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">I've noticed = that under Python3, PyOpenGL inconsistently expects 'str' = <br></blockquote><blockquote type=3D"cite">and 'bytes' objects as = function arguments. For some functions, I'd <br></blockquote><blockquote = type=3D"cite">expect to use 'str' while in the current implementation = 'bytes' is used.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">E.g. in = glGetUniformlocation, the name of the uniform is to be = <br></blockquote><blockquote type=3D"cite">specified as a 'bytes' = object, while I would expect to use 'str' since = <br></blockquote><blockquote type=3D"cite">it is a name. Also, = shaders.compileShader takes a 'str' for the shader = <br></blockquote><blockquote = type=3D"cite">code<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Similarly, = extensions.hasGLExtension() expects a 'str' object for the = <br></blockquote><blockquote type=3D"cite">extension name, but = extension.AVAILABLE_GL_EXTENSIONS is a list of = <br></blockquote><blockquote = type=3D"cite">'bytes'.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Of course, for = arguments dealing with binary data (e.g. glTexImage2D), = <br></blockquote><blockquote type=3D"cite">a 'bytes' object is to be = used.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Apart from the = actual implementation, has there been any thought on = <br></blockquote><blockquote type=3D"cite">how to expose things like = uniform names to the user?<br></blockquote>My first reaction would be to = do this:<br><br> if isinstance( arg, = unicode):<br> arg =3D = arg.encode( 'latin-1' )<br><br>in the wrapper (the as_8_bit() hack has = been added to the extensions <br>module, for instance), that is, for = each argument which is current str, <br>make the argument capable of = accepting a unicode argument... as for <br>producing them... I'm = hesitant to convert the 8-bit values (which is <br>internally what = OpenGL is specifying; GLchar * is an 8-bit value) to <br>unicode = arbitrarily, as now code that uses formal, correct, byte-strings <br>is = going to crash when it tries to interact with the generated unicode = <br>values.<br><br>Everything in OpenGL is binary data. Everything has = an expressly defined <br>binary representation, and that includes = byte-strings. Anything I do <br>here to paper over the difference = is, I expect, going to come back to <br>byte us in the future. = Someone is going to do a glGetActiveUniform() in = <br>my_unicode_shader and have it blow up on a unicode/bytes = disagreement if <br>I convert on return, or is going to do = glGetActiveUniform() in <br>my_bytes_shader if I don't, but I expect = that the number of problems <br>with glGetUniform( 'myuniform' ) will be = substantial.<br><br>Basically I don't have a good solution. Either = we create an API <br>inconsistency between Python 2 and Python 3 = (returning "str" in both, <br>though they are different types), or we = make Python 3 users explicitly <br>deal with the return-type of the = GLchar* calls and/or use byte-strings = <br>everywhere.<br><br>Enjoy,<br>Mike<br><br>-- = <br>________________________________________________<br> = Mike C. Fletcher<br> Designer, VR Plumber, = Coder<br> <a = href=3D"http://www.vrplumber.com">http://www.vrplumber.com</a><br> = <a = href=3D"http://blog.vrplumber.com">http://blog.vrplumber.com</a><br><br><b= r>------------------------------------------------------------------------= ------<br>Better than sec? Nothing is better than sec when it comes = to<br>monitoring Big Data applications. Try Boundary one-second = <br>resolution app monitoring today. Free.<br><a = href=3D"http://p.sf.net/sfu/Boundary-dev2dev">http://p.sf.net/sfu/Boundary= -dev2dev</a><br>_______________________________________________<br>PyOpenG= L = Homepage<br>http://pyopengl.sourceforge.net<br>___________________________= ____________________<br>PyOpenGL-Devel mailing = list<br>[email protected]<br>https://lists.sourceforge.= net/lists/listinfo/pyopengl-devel<br></div></blockquote></div><br></div></= div></body></html>= --Apple-Mail-23-990721308-- --===============8311410698500747043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev --===============8311410698500747043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PyOpenGL Homepage http://pyopengl.sourceforge.net _______________________________________________ PyOpenGL-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pyopengl-devel --===============8311410698500747043==--