Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > pygame - importing GL - very bad...

Reply
Thread Tools

pygame - importing GL - very bad...

 
 
Chris Angelico
Guest
Posts: n/a
 
      01-02-2013
On Thu, Jan 3, 2013 at 4:52 AM, Ian Kelly <(E-Mail Removed)> wrote:
> On Wed, Jan 2, 2013 at 7:32 AM, Chris Angelico <(E-Mail Removed)> wrote:
>> Okay, I have to ask... why? Does it have an exception for names of classes?

>
> Yes, and for module-level functions.


Oh, okay. So the check's a lot more specific than the message implies
- it applies only to non-callable module level names. I guess that's
reasonable.

>> I don't like linters that enforce too much style. Catch things that
>> might be mis-coded (like C's classic "if (x = 1)"), but don't complain
>> about my names. They're MY business.

>
> pylint is configurable though, so you can disable any warnings you
> don't care about. My pylint macro has a fairly large number of -d
> options in it.


Yeah, same applies to most linters I think. You end up disagreeing
with the author on half the points. Oh well. Doesn't make the tool
useless, just means you need to fiddle with it to get it how you want
it.

ChrisA
 
Reply With Quote
 
 
 
 
Ian Kelly
Guest
Posts: n/a
 
      01-02-2013
On Wed, Jan 2, 2013 at 10:57 AM, Chris Angelico <(E-Mail Removed)> wrote:
> Yeah, same applies to most linters I think. You end up disagreeing
> with the author on half the points. Oh well. Doesn't make the tool
> useless, just means you need to fiddle with it to get it how you want
> it.


It's a lot less work to disable a check than to implement a desired
check that is missing, so to me it's better that a linter do too much
by default than not enough.
 
Reply With Quote
 
 
 
 
Michael Torrie
Guest
Posts: n/a
 
      01-02-2013
On 01/01/2013 04:49 PM, someone wrote:
> On 01/01/2013 12:13 PM, Chris Angelico wrote:
> > You could simply
> >
> > import OpenGL.GL as GL

> You're right - but I forgot to write that even though this maybe
> should/is recommended many places then I've seen a lot of opengl code on
> the internet and IMHO NOBODY does that and it'll be a lot slower to type
> that in front of all the opengl commands...
>
> So this solution is not something I like too... But I can see some other
> people came up with good solutions, which I didn't knew about..


Why is this solution not to your liking? Python has namespaces for a
reason. They both keep code separated and modular. Use them. At most
you should import the most commonly-used symbols only, and refer to the
rest through their respective namespaces (with whatever alias you've
given the import). There is no additional typing burden.

Despite your opinion, it is completely false that "NOBODY does [this]."
In other words a decent python programmer rarely does "from blah import
*." There's a reason why pylint flags this. Frankly the code you've
seen on the internet that does this is not setting a good example. It's
bad programming practice, plain and simple. I'm a bit surprised that
others on this list in this thread intimated that it's okay to do import
*. The only place where I've seen an import * that actually belonged
was in an __init__.py that brought sub-module symbols into the main
package namespace, and even then I figure there's got to be a better way.

Maybe this is your own private pet project, but if you ever plan to
involve others in your development, leaving the OpenGL symbols in their
own namespaces will make code maintenance a lot easier down the line.
Later on another developer may come along and if it's not easy to tell
at a glance if a symbol is provided by another module or if it's
something you defined, he's going to have a lot of unnecessary work.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      01-02-2013
On Wed, 02 Jan 2013 09:26:32 -0500, Dave Angel wrote:

> On 01/02/2013 09:09 AM, someone wrote:
>> On 01/02/2013 01:07 PM, Peter Otten wrote:


>>> pylint wants global names to be uppercase (what PEP 8 recommends for
>>> constants) or "special" (two leading and two trailing underscores):
>>>
>>> THATS_OK = 42
>>> __thats_ok_too__ = object()
>>> but_thats_not = "spam"

>>
>> OMG... I don't want to type those underscores everywhere... Anyway,
>> thank you very much for explaining the meaning of what it wants...
>>
>>
>>
>>

> Global const values should be ALL_CAPS, so it's obvious that nobody
> intends to modify them.


Like math.pi I suppose? *wink*


> It's the non-const global attributes that expect to be underscored.


Pylint is wrong here.

The double-leading-and-trailing-underscore naming scheme is reserved for
Python itself. PEP 8 explicitly states not to invent your own "dunder"
names:

__double_leading_and_trailing_underscore__: "magic" objects or
attributes that live in user-controlled namespaces. E.g. __init__,
__import__ or __file__. Never invent such names; only use them as
documented.


The section on global variables does not say to use dunder names:

http://www.python.org/dev/peps/pep-0008/#id31


If pylint says that global variables should be named like "__variable__",
that is explicitly going against PEP 8.


> You shouldn't have to use those underscores very often. After all,
> there is seldom a need for a non-const global value, right? Don't think
> of it as a pylint problem, but as a hint from pylint that perhaps you
> should use fewer globals.


That at least is good advice.


--
Steven
 
Reply With Quote
 
someone
Guest
Posts: n/a
 
      01-03-2013
On 01/02/2013 10:57 PM, Michael Torrie wrote:
> On 01/01/2013 04:49 PM, someone wrote:
>> On 01/01/2013 12:13 PM, Chris Angelico wrote:
>> > You could simply
>> >
>> > import OpenGL.GL as GL

>> You're right - but I forgot to write that even though this maybe
>> should/is recommended many places then I've seen a lot of opengl code on
>> the internet and IMHO NOBODY does that and it'll be a lot slower to type
>> that in front of all the opengl commands...
>>
>> So this solution is not something I like too... But I can see some other
>> people came up with good solutions, which I didn't knew about..

>
> Why is this solution not to your liking? Python has namespaces for a


Because the amount of opengl-functions is HUGE, many people (at least on
the internet) do as I and (IMHO) it takes up too much time to change a
lot of code plus sometimes I grab/modify small code pieces from the
internet and it makes my development SO MUCH faster just to make an
exception here with star-import for opengl-commands.

> reason. They both keep code separated and modular. Use them. At most
> you should import the most commonly-used symbols only, and refer to the
> rest through their respective namespaces (with whatever alias you've
> given the import). There is no additional typing burden.


There are SO MANY "common-only used" symbols, but I also once believed
that I should do as you write (which I agree with you, is the correct
way to do it). I'm not saying you're incorrect - I just say that it
speeds up my development significantly to only use star-import for
opengl-stuff.

> Despite your opinion, it is completely false that "NOBODY does [this]."
> In other words a decent python programmer rarely does "from blah import
> *." There's a reason why pylint flags this. Frankly the code you've
> seen on the internet that does this is not setting a good example. It's
> bad programming practice, plain and simple. I'm a bit surprised that
> others on this list in this thread intimated that it's okay to do import
> *. The only place where I've seen an import * that actually belonged


Generally you're completely correct. After having worked with opengl for
some time however, I must say that my personal opinion is that the
benefits of making an exception here outweights the disadvantages a lot
- but only for the many MANY opengl-commands.

> was in an __init__.py that brought sub-module symbols into the main
> package namespace, and even then I figure there's got to be a better way.
>
> Maybe this is your own private pet project, but if you ever plan to
> involve others in your development, leaving the OpenGL symbols in their
> own namespaces will make code maintenance a lot easier down the line.


As said, you're completely correct. Until now it's my own private
project, though I'm considering making it open-source after some time.
Right now I just need to develop as quick as possible because I have a
lot of work to do.

> Later on another developer may come along and if it's not easy to tell
> at a glance if a symbol is provided by another module or if it's
> something you defined, he's going to have a lot of unnecessary work.


Don't worry about that - opengl programmers immediately see and
recognize opengl-commands... This, I deem is absolutely not a problem -
opengl programmers easily recognize opengl commands immediately. They
also usually begin with GL_.... - hence it's quite easy to see what is
an opengl command and everything that isn't an opengl-command is (as you
suggest) NOT imported using "star"-import.


 
Reply With Quote
 
someone
Guest
Posts: n/a
 
      01-03-2013
On 01/02/2013 11:30 PM, Andrew Berg wrote:
> On 2013.01.02 15:57, Michael Torrie wrote:


>> *. The only place where I've seen an import * that actually belonged
>> was in an __init__.py that brought sub-module symbols into the main
>> package namespace, and even then I figure there's got to be a better way.

> This.
>
> I have some code that imports multiprocessing.connection and I do
> actually type out multiprocessing.connection.Client and it doesn't
> bother me one bit. Code is read a lot more than it is written, even if
> only one person ever sees it. The whole "less typing" thing is absurd,
> especially when IDEs have completion features and stdlib modules share


Until about a week ago, actually I hadn't setup emacs to use code
completion - maybe this will change now because it'll speed things up
and code completion is just a wonderful thing making things easier +
quicker to do. I also setup emacs to do use TAGS and a lot more things now.

> similar or exact function names (is it subprocess.Popen or os.popen? I
> guess the author wanted to save 2 seconds typing while anyone who reads
> it has to spend 5-10 to find out which is being used) . I've been using


Well, this is not a problem for opengl-commands, I think... Normally I
do as you suggest and for the exact same reasons as you write.

> full namespaces since I started learning Python, and I even do it at the
> interactive interpreter because it's just a habit. IMO, "from foo import
> *" should only ever be used for /intentional/ namespace pollution (and
> even then, there are probably better ways to do it).


But I don't do any pollution - only this "format", which was a false
alert. And so far I'm so consequent to only use it for the
opengl-commands. I would deem that this is what most opengl-programmers do.

Try to search for opengl-code out there on the internet... Most people
do as I write I do here, IMHO. But you have a point and generally I
totally agree with you. This is just a particular exception (and the
only one I have) where I disagree, because I do as I think the majority
of opengl-programmers do - based on what I see posted on the internet.






 
Reply With Quote
 
someone
Guest
Posts: n/a
 
      01-03-2013
On 01/02/2013 03:26 PM, Dave Angel wrote:
> On 01/02/2013 09:09 AM, someone wrote:
>> On 01/02/2013 01:07 PM, Peter Otten wrote:
>> OMG... I don't want to type those underscores everywhere... Anyway,
>> thank you very much for explaining the meaning of what it wants...
>>
>>
>>

>
> Global const values should be ALL_CAPS, so it's obvious that nobody
> intends to modify them. It's the non-const global attributes that
> expect to be underscored.
>
> You shouldn't have to use those underscores very often. After all,
> there is seldom a need for a non-const global value, right? Don't think


I suppose you're right.

> of it as a pylint problem, but as a hint from pylint that perhaps you
> should use fewer globals.


I had some bad code which I improved greatly now with thanks to pylint.
I'll remember what you've written the next time I look at it - I think I
don't use that many global non-const values now - I wrapped a lot of
things into a class now. This is much better and I guess the correct
"object-oriented" thing to do. I hope/think I'll get this warning a lot
fewer times in the future.

Thanks a lot for the explanation.





 
Reply With Quote
 
someone
Guest
Posts: n/a
 
      01-03-2013
On 01/03/2013 12:52 AM, Steven D'Aprano wrote:
> On Wed, 02 Jan 2013 09:26:32 -0500, Dave Angel wrote:


>> Global const values should be ALL_CAPS, so it's obvious that nobody
>> intends to modify them.

>
> Like math.pi I suppose? *wink*




>> It's the non-const global attributes that expect to be underscored.

>
> Pylint is wrong here.


Ok, forget my previous post - now I looked a bit deeper into it again.
Consider this as an example:

------------------------
# Global mouse states = global constants:
M_LEFT = 1
M_MIDDLE = 2
M_RIGHT = 3
M_WHEEL_UP = 4
M_WHEEL_DOWN = 5

class somethingWork:
""" OpenGL something class """

def __init__(self, someInputFile):
self.inputFile = someInputFile
self.running = False
# self.viewport = (800,600)
self.viewport = (1024, 76
self.lightDone = False
self.rx = 0 # rotation x
self.ry = 0 # rotation y
self.rz = 0 # rotation z
.... etc ...
------------------------

What pylint says is:

1) class somethingWork: Invalid name "somethingWork" (should match
[A-Z_][a-zA-Z0-9]+$), I'm not that good at regular exps, but I suppose
it wants my class name to start with a capital letter ?

2) self.lightDone: Invalid name "lightDone" (should match
[a-z_][a-z0-9_]{2,30}$)

So I can now understand that pylint doesn't like my naming convention
with a capital letter in the middle of the variable name, like:
"lightDone" = a boolean value. I suppose pylint wants me to use (a
little longer method) an underscore to separate words in long variable
names...

3) self.rx / rself.ry / self.rz: Invalid name "rx" (should match
[a-z_][a-z0-9_]{2,30}$) - so I suppose it wants this name to end with an
underscore ?

I have a lot of these warnings...

> The double-leading-and-trailing-underscore naming scheme is reserved for
> Python itself. PEP 8 explicitly states not to invent your own "dunder"
> names:
>
> __double_leading_and_trailing_underscore__: "magic" objects or
> attributes that live in user-controlled namespaces. E.g. __init__,
> __import__ or __file__. Never invent such names; only use them as
> documented.


I think I would also never use __something__ names...

> The section on global variables does not say to use dunder names:
>
> http://www.python.org/dev/peps/pep-0008/#id31


Thanks a lot for this reference...

> If pylint says that global variables should be named like "__variable__",
> that is explicitly going against PEP 8.


I don't think that is what it's saying... But I think it wants me to use
more underscores, i.e. self.lightDone => self.light_done I think...

>> You shouldn't have to use those underscores very often. After all,
>> there is seldom a need for a non-const global value, right? Don't think
>> of it as a pylint problem, but as a hint from pylint that perhaps you
>> should use fewer globals.

>
> That at least is good advice.


Ok, sorry for my previous post. This post better explains how I've named
my variables. I don't like it complains about a simple and good variable
name as self.rx, self.ry, self.rz and so on. These are IMHO very good
variable names: rotation about x, y and z. Short and precise/accurate.
I'm not sure if I'll agree with all the warnings it comes up with. But I
think I could maybe introduce more use of underscores in the middle of
my variable names, in the future...

Thanks for the extra + good explanations.






 
Reply With Quote
 
someone
Guest
Posts: n/a
 
      01-03-2013
On 01/02/2013 08:31 PM, Ian Kelly wrote:
> On Wed, Jan 2, 2013 at 10:57 AM, Chris Angelico <(E-Mail Removed)> wrote:
>> Yeah, same applies to most linters I think. You end up disagreeing
>> with the author on half the points. Oh well. Doesn't make the tool
>> useless, just means you need to fiddle with it to get it how you want
>> it.

>
> It's a lot less work to disable a check than to implement a desired
> check that is missing, so to me it's better that a linter do too much
> by default than not enough.


I just started using pylint and some of the stuff it came up with is
REALLY good - so I'll definately use pylint, pep8 (and friends) more in
the future. And I think I'll also get to a point where I'll disable some
of the checks - as one of you wrote: How I name my variables is (maybe)
my own business and for instance I like a short variable name once in a
while, e.g. "rx", "ry", "rz" for rotation around x- y- and z-axises and
these variable names should not be changed.

But can I ask you something: English is not my native language and I
looked up what "linter" means - but it's not in my dictionary. What doet
"linter" mean ?

I don't suppose these exlanations are the same as you would give, in the
context you're using?

http://www.wordreference.com/definition/linter
http://www.collinsdictionary.com/dic...merican/linter
http://www.merriam-webster.com/dictionary/linter

?

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      01-03-2013
On 1/2/2013 9:24 PM, someone wrote:

> What pylint says is:
>
> 1) class somethingWork: Invalid name "somethingWork" (should match
> [A-Z_][a-zA-Z0-9]+$), I'm not that good at regular exps, but I suppose
> it wants my class name to start with a capital letter ?


Yes
>
> 2) self.lightDone: Invalid name "lightDone" (should match
> [a-z_][a-z0-9_]{2,30}$)
>
> So I can now understand that pylint doesn't like my naming convention
> with a capital letter in the middle of the variable name, like:
> "lightDone" = a boolean value. I suppose pylint wants me to use (a
> little longer method) an underscore to separate words in long variable
> names...


That is more conventional in the Python community (and is in pep 8, I
believe) but still a choice.

> 3) self.rx / rself.ry / self.rz: Invalid name "rx" (should match
> [a-z_][a-z0-9_]{2,30}$) - so I suppose it wants this name to end with an
> underscore ?


No, it allows underscores. As I read that re, 'rx', etc, do match. They
are two chars in the indicated sets. I disagree with requiring 2 chars,
as .x, .y, are sometimes quite appropriate.

--
Terry Jan Reedy

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[pygame-bug] Pygame.cdrom bug rantingrick Python 1 01-30-2011 04:40 AM
[pygame] Very simple program fails. Why? Brent W. Hughes Python 2 04-27-2005 10:24 PM
very very very long integer shanx__=|;- C Programming 19 10-19-2004 03:55 PM
Quick Book file access very very very slow Thomas Reed Computer Support 7 04-09-2004 08:09 PM
very Very VERY dumb Question About The new Set( ) 's Raymond Arthur St. Marie II of III Python 4 07-27-2003 12:09 AM



Advertisments