pygame - importing GL - very bad...

[Chris Angelico]

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.

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

 

[Ian Kelly]

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.

 

[Michael Torrie]

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.

 

[Steven D'Aprano]

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.

 

[someone]

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.

 

[someone]

On 2013.01.02 15:57, Michael Torrie wrote:
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.

 

[someone]

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.

 

[someone]

Like math.pi I suppose? *wink*



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, 768)
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...

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.

 

[someone]

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/dictionary/american/linter
http://www.merriam-webster.com/dictionary/linter

?

 

[Terry Reedy]

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.

 

[Ian Kelly]

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, PEP-8 recommends CamelCase for class names.

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...

Also yes.

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 ?

It wants the name to be at least 3 characters long.

 

[Chris Rebert]

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, PEP-8 recommends CamelCase for class names.

PEP 8 discourages camelCase for names except for compatibility purposes,
and recommends TitleCase for class names.

If we must quibble over meta-nomenclature...
http://www.python.org/dev/peps/pep-0008/ :
"""
The following naming styles are commonly distinguished:
[...]
* CapitalizedWords (or CapWords, or CamelCase -- so named because of
the bumpy look of its letters [3]). […]
* mixedCase (differs from CapitalizedWords by initial lowercase character!)
"""

The term "TitleCase" does not make an appearance in the document.

Regards,
Chris

 

[Peter Otten]

[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

No, it's one leading letter or underscore [a-z_] plus at least two letters,
underscores or digits [a-z0-9_]{2,30}

 

[someone]

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 ?

It wants the name to be at least 3 characters long.

Uh, ok, thank you. I'll remember that.

Doesn't this "[ ... ]" mean something optional?

What does {2,30}$ mean?

I think $ means that the {2,30} is something in the end of the sentence...

 

[someone]

[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

No, it's one leading letter or underscore [a-z_] plus at least two letters,
underscores or digits [a-z0-9_]{2,30}

Ah, [a-z0-9_]{2,30} means there should be at least two characters and
maximum 30 characters here ?

 

[Chris Angelico]

Doesn't this "[ ... ]" mean something optional?

What does {2,30}$ mean?

I think $ means that the {2,30} is something in the end of the sentence...

You can find regular expression primers all over the internet, but to
answer these specific questions: [...] means any of the characters in
the range; the $ means "end of string"; and {2,30} means at least two,
and at most thirty, of the preceding character. So you have to have
one from the first group, then 2-30 from the second, for a total of
3-31 characters in your names.

ChrisA

 

[Peter Otten]

[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

No, it's one leading letter or underscore [a-z_] plus at least two
letters, underscores or digits [a-z0-9_]{2,30}

Ah, [a-z0-9_]{2,30} means there should be at least two characters and
maximum 30 characters here ?

Yes. See

http://docs.python.org/2/library/re.html#regular-expression-syntax

 

[Mike C. Fletcher]

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.

I'd agree on it being rather impractical/pointless/verbose to have every
single OpenGL entry point and constant have an extra gl. or glu. or
glut. added to the front. OpenGL/GLU/GLUT is already namespaced, but
using C-style prefix namespacing (that is gl* glu* glut* and GL_*,
GLU_*, GLUT_*), so adding Python style namespacing to the front of that
makes it very verbose. OpenGL-using code is *littered* with OpenGL
entry points and constants (and yes, I intend the slight slight), so
that's going to make it rather annoying to work with.

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)

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)

Either of which would *also* make it possible for us to lazy-load the
entry points and symbols (that would save quite a bit of ram).

But I'm not actually likely to do this, as it makes it far more annoying
to work with C-oriented references (and since PyOpenGL is primarily used
by new OpenGL coders who need to lean heavily on references, that's a
big deal). Currently you can often copy-and-paste C code into PyOpenGL
and have it work properly as far as the OpenGL part is concerned (arrays
and the like need to be rewritten, but that's not something I can
control, really). People are already confused by the small variations
from C OpenGL, making the API look entirely different wouldn't be a good
direction to move, IMO.

HTH,
Mike

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

 

[Mike C. Fletcher]

On 13-01-02 09:48 PM, Terry Reedy wrote:
....

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.

That seems like a improper error message from the tool. "Invalid name"
does *not* properly describe that situation. The name is *not*
"Invalid" in any sense of the word, and a "checker" that tells you it is
is creating needless false-positives. An error checker should be saying
something like:

"self.lightDone: Does not match PEP8 recommended style"

making it clear that this is *not* an error, it is a *style* related
*warning*.

HTH,
Mike

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

 

[Terry Reedy]

On 13-01-02 09:48 PM, Terry Reedy wrote:
...

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.

That seems like a improper error message from the tool. "Invalid name"
does *not* properly describe that situation. The name is *not*
"Invalid" in any sense of the word, and a "checker" that tells you it is
is creating needless false-positives. An error checker should be saying
something like:

"self.lightDone: Does not match PEP8 recommended style"

making it clear that this is *not* an error, it is a *style* related
*warning*.

I quite agree. Wanting 3 chars for attribute names is not even PEP-8
style but pylint-author style. I was really surprised at that. In that
case, 'Does not match pylint recommended style.' or even 'configured
styles'. I have not used pylint or pychecker as of yet.