pygame - importing GL - very bad...
d at davea.name
Sat Jan 5 02:30:47 CET 2013
On 01/04/2013 08:10 PM, someone wrote:
> On 01/03/2013 03:09 PM, Mike C. Fletcher wrote:
>> PyOpenGL's current approach is mostly attempting to maintain backward
>> compatibility with the older revisions. wxPython actually rewrote its
>> whole interface to go from * imports into namespaced lookups and then
>> wrote a little migration tool that would attempt to rewrite your code
>> for the new version. They also provided a transitional API so that code
>> could mix-and-match the styles. For PyOpenGL that would look something
>> like this:
>> from OpenGL import gl, glu, glut
> Ok, that's interesting. However, I like it the way it is, where I can
> copy/paste C-code from the web and change some small things and it'll
> work and fit into my needs. BUT I didn't know there was such a
> transitional API - interesting. I however don't want to be a
> first-mover - let's see if sufficiently many people will use this and
> then I'll consider doing it too. At the moment, I still think the
> star-import is good because it makes it easy to look for C-code and
> program it (=do it) like people would do it in C.
>> or, if you really needed PEP-8 compliance, and don't mind making the API
>> look nothing like the original, we might even go to:
>> from opengl import gl, glu, glut
> Erhm, that's the same as above. Is that what you meant to write?
No, it's not the same; here he did not capitalize the function names.
Previously they look like class instantiations.
> Well, I'm sometimes a bit annoyed that python doesn't give as many
> warnings/errors as one gets in C - for instance sometimes I copy/paste
> and forget to remove the trailing semi-colons.
Trailing semi colons are legal in most cases. The semi-colon is a
separator between statements, when one wants to put multiple statements
on one line.
> However after I began to use pylint and friends, this error will be
> caught. Then sometimes I forgot to add () for function calls, which in
> C would cause an error by the compiler
Actually no. In C, a function name without parentheses is also a
function pointer. Not exactly the same as a function object, though C++
gets a lot closer. But the real reason C catches that typo is that the
types most likely don't match, depending on what you meant to do with
the return value.
> but which python allows so one can get the object (which maybe is also
> a good reason, but at least in the beginning when I learned python,
> this was very annoying + confusing to me).
Function objects are enormously useful, as you get more adept at using
More information about the Python-list