Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!feed.xsnews.nl!border-1.ams.xsnews.nl!xlned.com!feeder7.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Fri, 04 Jan 2013 20:30:47 -0500
From: Dave Angel <d@davea.name>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: pygame - importing GL - very bad...
References: <kbufkg$ead$1@dont-email.me> <mailman.1512.1357038843.29569.python-list@python.org> <kbvslg$mqg$1@dont-email.me> <mailman.1.1357163829.2939.python-list@python.org> <kc2oa0$3e3$1@dont-email.me> <mailman.38.1357222158.2939.python-list@python.org> <kc7uia$8h1$1@dont-email.me>
In-Reply-To: <kc7uia$8h1$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: d@davea.name
Newsgroups: comp.lang.python
Message-ID: <mailman.104.1357349785.2939.python-list@python.org>
Lines: 74
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:36148

On 01/04/2013 08:10 PM, someone wrote:
> On 01/03/2013 03:09 PM, Mike C. Fletcher wrote:
>> <snip>
>
>> 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
>>
>> gl.Rotate(...)
>> gl.Clear(gl.COLOR_BUFFER_BIT)
>
> 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
>>
>> gl.rotate(...)
>> gl.clear(gl.COLOR_BUFFER_BIT)
>
> 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.

> <snip>
>
> 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
Python.



-- 

DaveA