Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #35882 > unrolled thread

pygame - importing GL - very bad...

Back to article view | Back to comp.lang.python

Contents

  pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-01 12:00 +0100
    Re: pygame - importing GL - very bad... Chris Angelico <rosuav@gmail.com> - 2013-01-01 22:13 +1100
      Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 00:49 +0100
        Re: pygame - importing GL - very bad... Michael Torrie <torriem@gmail.com> - 2013-01-02 14:57 -0700
          Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-03 02:53 +0100
            Re: pygame - importing GL - very bad... "Mike C. Fletcher" <mcfletch@vrplumber.com> - 2013-01-03 09:09 -0500
              Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 02:10 +0100
                Re: pygame - importing GL - very bad... Dave Angel <d@davea.name> - 2013-01-04 20:30 -0500
                  Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 11:49 +0100
                    Re: pygame - importing GL - very bad... Dave Angel <d@davea.name> - 2013-01-05 06:23 -0500
                    Re: pygame - importing GL - very bad... Chris Angelico <rosuav@gmail.com> - 2013-01-05 22:47 +1100
                      Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 14:06 +0100
                        Re: pygame - importing GL - very bad... Chris Angelico <rosuav@gmail.com> - 2013-01-06 00:27 +1100
                          Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 20:49 +0100
                            Re: pygame - importing GL - very bad... alex23 <wuwei23@gmail.com> - 2013-01-06 03:37 -0800
                              Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-06 13:46 +0100
        Re: pygame - importing GL - very bad... Andrew Berg <bahamutzero8825@gmail.com> - 2013-01-02 16:30 -0600
          Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-03 03:02 +0100
    Re: pygame - importing GL - very bad... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-01 11:49 +0000
      Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 00:49 +0100
        Re: pygame - importing GL - very bad... Nobody <nobody@nowhere.com> - 2013-01-02 03:01 +0000
          Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 04:43 +0100
          Re: pygame - importing GL - very bad... alex23 <wuwei23@gmail.com> - 2013-01-02 01:52 -0800
            Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 15:04 +0100
        Re: pygame - importing GL - very bad... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-02 07:39 +0000
          Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 15:06 +0100
    Re: pygame - importing GL - very bad... Peter Otten <__peter__@web.de> - 2013-01-01 13:56 +0100
      Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 00:50 +0100
        pylint, was Re: pygame - importing GL - very bad... Peter Otten <__peter__@web.de> - 2013-01-02 13:07 +0100
          Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 15:09 +0100
            Re: pylint, was Re: pygame - importing GL - very bad... Dave Angel <d@davea.name> - 2013-01-02 09:26 -0500
              Re: pylint, was Re: pygame - importing GL - very bad... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-02 23:52 +0000
                Re: pylint, was Re: pygame - importing GL - very bad... Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-02 17:25 -0700
                Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-03 03:24 +0100
                  Re: pylint, was Re: pygame - importing GL - very bad... Terry Reedy <tjreedy@udel.edu> - 2013-01-02 21:48 -0500
                  Re: pylint, was Re: pygame - importing GL - very bad... Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-02 19:55 -0700
                    Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-03 12:19 +0100
                      Re: pylint, was Re: pygame - importing GL - very bad... Chris Angelico <rosuav@gmail.com> - 2013-01-03 22:27 +1100
                        Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 02:11 +0100
                          Re: pylint, was Re: pygame - importing GL - very bad... Jan Riechers <janpeterr@freenet.de> - 2013-01-05 14:49 +0200
                            Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 14:09 +0100
                  Re: pylint, was Re: pygame - importing GL - very bad... Ben Finney <ben+python@benfinney.id.au> - 2013-01-03 17:01 +1100
                  Re: pylint, was Re: pygame - importing GL - very bad... Chris Rebert <clp2@rebertia.com> - 2013-01-02 22:33 -0800
                  Re: pylint, was Re: pygame - importing GL - very bad... Peter Otten <__peter__@web.de> - 2013-01-03 10:00 +0100
                    Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-03 12:21 +0100
                      Regular expression syntax, was Re: pylint, was Re: pygame - importing GL - very bad... Peter Otten <__peter__@web.de> - 2013-01-03 12:39 +0100
                        Re: Regular expression syntax, was Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 02:12 +0100
                  Re: pylint, was Re: pygame - importing GL - very bad... "Mike C. Fletcher" <mcfletch@vrplumber.com> - 2013-01-03 09:19 -0500
                  Re: pylint, was Re: pygame - importing GL - very bad... Terry Reedy <tjreedy@udel.edu> - 2013-01-03 11:52 -0500
                    Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 02:14 +0100
              Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-03 03:06 +0100
        Re: pylint, was Re: pygame - importing GL - very bad... Chris Angelico <rosuav@gmail.com> - 2013-01-03 01:32 +1100
        Re: pylint, was Re: pygame - importing GL - very bad... Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-02 10:52 -0700
        Re: pylint, was Re: pygame - importing GL - very bad... Chris Angelico <rosuav@gmail.com> - 2013-01-03 04:57 +1100
        Re: pylint, was Re: pygame - importing GL - very bad... Ian Kelly <ian.g.kelly@gmail.com> - 2013-01-02 12:31 -0700
          Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-03 03:31 +0100
            Re: pylint, was Re: pygame - importing GL - very bad... Dave Angel <d@davea.name> - 2013-01-02 21:56 -0500
              Re: pylint, was Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-05 02:23 +0100
    Re: pygame - importing GL - very bad... alex23 <wuwei23@gmail.com> - 2013-01-01 14:39 -0800
      Re: pygame - importing GL - very bad... someone <newsboost@gmail.com> - 2013-01-02 00:56 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#35952

On Wed, 02 Jan 2013 00:49:36 +0100, someone wrote:

> In [11]: del format
> ---------------------------------------------------------------------------
> NameError                                 Traceback (most recent call last)
> <ipython-input-11-028e6ffb84a8> in <module>()
> ----> 1 del format
> 
> NameError: name 'format' is not defined
> --------
> 
> What does this mean? Why does it say 'format" cannot be deleted after I 
> did the wildcard import ?

You can't delete built-in names. 

It has nothing to do with the wildcard import. The PyOpenGL modules delete
"format" from the module's variables as soon as they are finished with
it, so the set of names created by the wildcard import doesn't include
"format".

[toc] | [prev] | [next] | [standalone]

#35953

On 01/02/2013 04:01 AM, Nobody wrote:
> On Wed, 02 Jan 2013 00:49:36 +0100, someone wrote:
>
>> In [11]: del format
>> ---------------------------------------------------------------------------
>> NameError                                 Traceback (most recent call last)
>> <ipython-input-11-028e6ffb84a8> in <module>()
>> ----> 1 del format
>>
>> NameError: name 'format' is not defined
>> --------
>>
>> What does this mean? Why does it say 'format" cannot be deleted after I
>> did the wildcard import ?
>
> You can't delete built-in names.

Ah, ok - and cannot overwrite it too, I guess... A shame that pylint 
didn't knew about this.

> It has nothing to do with the wildcard import. The PyOpenGL modules delete
> "format" from the module's variables as soon as they are finished with
> it, so the set of names created by the wildcard import doesn't include
> "format".

Ok, sounds to me like I can safely ignore this pylint warning in any 
case... Thanks!

[toc] | [prev] | [next] | [standalone]

#35968

On Jan 2, 1:01 pm, Nobody <nob...@nowhere.com> wrote:
> You can't delete built-in names.

Actually, you can. If you ever need to shoot yourself in the foot in
this particular way, you can always do:

    del __builtins__.format

Not saying you _should_, just that you _can_ :)

[toc] | [prev] | [next] | [standalone]

#35980

On 01/02/2013 10:52 AM, alex23 wrote:
> On Jan 2, 1:01 pm, Nobody <nob...@nowhere.com> wrote:
>> You can't delete built-in names.
>
> Actually, you can. If you ever need to shoot yourself in the foot in
> this particular way, you can always do:
>
>      del __builtins__.format
>
> Not saying you _should_, just that you _can_ :)

Ok, good to know (not saying I would ever try it) :-)

[toc] | [prev] | [next] | [standalone]

#35965

On Wed, 02 Jan 2013 00:49:36 +0100, someone wrote:

> On 01/01/2013 12:49 PM, Steven D'Aprano wrote:
>  > On Tue, 01 Jan 2013 12:00:32 +0100, someone wrote:
>  >
>  >> See this code (understand why I commented out first line):
>  >>
>  >> # from OpenGL.GL import *
>  > [...]
>  >> The reason why I commented out the first line is that I use "pylint"
>  >> and it reports: "[W] Redefining built-in 'format'" for this line.
>  >>
>  >> From: http://www.logilab.org/card/pylintfeatures tell: W0621:
>  >> Redefining name %r from outer scope (line %s) Used when a variable's
>  >> name hide a name defined in the outer scope.
>  >>
>  >> I don't like to redefine already defined names so therefore I had to
>  >> outcomment first line and then keep on adding stuff until I could
>  >> run my program... But this SUCKS! I can see that pygame hasn't been
>  >> updated for a long while - not many users use it? I'm not very happy
>  >> about this...
>  >
>  > from pygame import *
>  > del format
> 
> Are you sure about this? Because I'm not (OTOH I'm maybe not as
> experienced in python as some of you)...

In the general case of deleting global names that shadow builtin names, 
yes I am.

In the specific case of importing * from pygame, no. I trusted you that 
pygame exports format. Unfortunately, it seems that you were fooled by an 
invalid warning from pylint, so we were both mistaken.


> Ipython log:
> 
> --------
> In [6]: test=format(43)
> In [7]: type(test)
> Out[7]: str
> In [8]: from pygame import *
> In [9]: test=format(43)
> In [10]: type(test)
> Out[10]: str
> In [11]: del format
> ------------------------------------------------------------------------
> NameError                              Traceback (most recent call last)
> <ipython-input-11-028e6ffb84a8> in <module>() 
> ----> 1 del format
> 
> NameError: name 'format' is not defined 
> --------
> 
> What does this mean? Why does it say 'format" cannot be deleted after I
> did the wildcard import ?

It means that there is no "format" in the current scope, which implies 
that pygame no longer has a "format" which can be imported.

You don't need an import to shadow built-ins. See for example:

py> format
<built-in function format>
py> format = "NOBODY expects the Spanish Inquisition!"
py> format  # this shadows the built-in "format"
'NOBODY expects the Spanish Inquisition!'
py> del format  # get rid of the Spanish Inquisition
py> format 
<built-in function format>
py> del format
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'format' is not defined


When a name is not discovered in the current scope, the builtin scope is 
checked before Python gives up and reports a NameError. But del only 
works on the current scope, to stop you from accidentally deleting the 
wrong object.


>  > pylint may still complain, but you can ignore it. By deleting the
>  > name "format", that will unshadow the builtin format.
> 
> Are you sure?

Since it turns out that pylint was actually wrong to complain, no format 
was actually imported, then yes you can safely ignore it :-)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#35982

On 01/02/2013 08:39 AM, Steven D'Aprano wrote:
> On Wed, 02 Jan 2013 00:49:36 +0100, someone wrote:

>> What does this mean? Why does it say 'format" cannot be deleted after I
>> did the wildcard import ?
>
> It means that there is no "format" in the current scope, which implies
> that pygame no longer has a "format" which can be imported.
>
> You don't need an import to shadow built-ins. See for example:
>
> py> format
> <built-in function format>
> py> format = "NOBODY expects the Spanish Inquisition!"
> py> format  # this shadows the built-in "format"
> 'NOBODY expects the Spanish Inquisition!'
> py> del format  # get rid of the Spanish Inquisition
> py> format
> <built-in function format>
> py> del format
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> NameError: name 'format' is not defined

Ok, thank you very much - that was/is very illustrative...

> When a name is not discovered in the current scope, the builtin scope is
> checked before Python gives up and reports a NameError. But del only
> works on the current scope, to stop you from accidentally deleting the
> wrong object.

Ok, I'll remember that in the future, thank you.

>>   > pylint may still complain, but you can ignore it. By deleting the
>>   > name "format", that will unshadow the builtin format.
>>
>> Are you sure?
>
> Since it turns out that pylint was actually wrong to complain, no format
> was actually imported, then yes you can safely ignore it :-)

Ok, I can see from your example that you're right. Nice to know the real 
explanation, thank you very much. :-)

[toc] | [prev] | [next] | [standalone]

#35887

someone wrote:

> See this code (understand why I commented out first line):
> 
> # from OpenGL.GL import *
> from OpenGL.GL import glEnable, GL_DEPTH_TEST, \
>       glShadeModel, GL_SMOOTH, glClearColor, \
>       GL_CULL_FACE, GL_BLEND, glBlendFunc, \
>       GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, \
>       glClear, GL_COLOR_BUFFER_BIT, GL_DEPTH_BUFFER_BIT, \
>       glLoadIdentity, glTranslate, glRotate, \
>       glMultMatrixf, glPushMatrix, glCallList, \
>       glPopMatrix, glDisable, GL_LIGHTING
> 
> The reason why I commented out the first line is that I use "pylint" and
> it reports: "[W] Redefining built-in 'format'" for this line.
> 
> From: http://www.logilab.org/card/pylintfeatures tell:
> W0621: Redefining name %r from outer scope (line %s) Used when a
> variable's name hide a name defined in the outer scope.
> 
> I don't like to redefine already defined names so therefore I had to
> outcomment first line and then keep on adding stuff until I could run my
> program... But this SUCKS! I can see that pygame hasn't been updated for
> a long while - not many users use it? I'm not very happy about this...
> 
> Any good / clever solution to this problem, so I avoid this nasty crappy
> work-around?
> 
> Any ideas / suggestions ?
> Thanks.

It turns out pylint is lying. The situation is equivalent to

$ cat module.py
for format in [42]:
    pass
del format

$ cat main.py 
original_format = format
from module import *
assert format is original_format
$ python main.py

The assert doesn't trigger, so format is not redefined. But pylint complains 
anyway:

$ pylint main.py -rn
No config file found, using default configuration
************* Module main
W:  2: Redefining built-in 'format'
C:  1: Missing docstring
C:  1: Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
(__.*__))$)
W:  2: Wildcard import module

If you can ignore the warning about the wildcard import you should be able 
to ignore the "redefining built-in" warning, too. Personally I would avoid 
putting magic comments like

from module import * # pylint: disable=W0622

$ pylint main.py -rn
No config file found, using default configuration
************* Module main
I:  2: Locally disabling W0622
C:  1: Missing docstring
C:  1: Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
(__.*__))$)
W:  2: Wildcard import module

into the code.

[toc] | [prev] | [next] | [standalone]

#35932

On 01/01/2013 01:56 PM, Peter Otten wrote:
 > someone wrote:

 > It turns out pylint is lying. The situation is equivalent to
 >
 > $ cat module.py
 > for format in [42]:
 >      pass
 > del format
 >
 > $ cat main.py
 > original_format = format
 > from module import *
 > assert format is original_format
 > $ python main.py
 >
 > The assert doesn't trigger, so format is not redefined. But pylint 
complains
 > anyway:
 >
 > $ pylint main.py -rn
 > No config file found, using default configuration
 > ************* Module main
 > W:  2: Redefining built-in 'format'
 > C:  1: Missing docstring
 > C:  1: Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
 > (__.*__))$)
 > W:  2: Wildcard import module
 >
 > If you can ignore the warning about the wildcard import you should be 
able

In the case of opengl import, I'll ignore the wildcard import warning. 
But in other cases I'll likely look a bit into it and see if I can avoid 
it or at least change it to something like: "import OpenGL.GL as GL" etc.

 > to ignore the "redefining built-in" warning, too. Personally I would 
avoid
 > putting magic comments like
 >
 > from module import * # pylint: disable=W0622

Oh, I just learned something new now... How come I cannot type "#pylint: 
enable=W0622" in the line just below the import ?

Not so intuitively/logically for me...

 > $ pylint main.py -rn
 > No config file found, using default configuration
 > ************* Module main
 > I:  2: Locally disabling W0622
 > C:  1: Missing docstring
 > C:  1: Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
 > (__.*__))$)
 > W:  2: Wildcard import module
 >
 > into the code.

Thank you very much...

Another thing is that I don't understand this warning:

Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
 > (__.*__))$)

I get it everywhere... I don't understand how it wants me to label my 
variables... Maybe I should disable this warning to get rid of it...

[toc] | [prev] | [next] | [standalone]

#35970 — pylint, was Re: pygame - importing GL - very bad...

someone wrote:

> On 01/01/2013 01:56 PM, Peter Otten wrote:

>> from module import * # pylint: disable=W0622
> 
> Oh, I just learned something new now... How come I cannot type "#pylint:
> enable=W0622" in the line just below the import ?

With what intended effect?

> Another thing is that I don't understand this warning:
> 
> Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
>  > (__.*__))$)
> 
> I get it everywhere... I don't understand how it wants me to label my
> variables... Maybe I should disable this warning to get rid of it...

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"

[toc] | [prev] | [next] | [standalone]

#35985 — Re: pylint, was Re: pygame - importing GL - very bad...

On 01/02/2013 01:07 PM, Peter Otten wrote:
> someone wrote:
>
>> On 01/01/2013 01:56 PM, Peter Otten wrote:
>
>>> from module import * # pylint: disable=W0622
>>
>> Oh, I just learned something new now... How come I cannot type "#pylint:
>> enable=W0622" in the line just below the import ?
>
> With what intended effect?

If I have a section with A LOT OF warnings and I don't want those in 
that section to show up ? Isn't that valid enough?

>> Another thing is that I don't understand this warning:
>>
>> Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
>>   > (__.*__))$)
>>
>> I get it everywhere... I don't understand how it wants me to label my
>> variables... Maybe I should disable this warning to get rid of it...
>
> 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...

[toc] | [prev] | [next] | [standalone]

#35991 — Re: pylint, was Re: pygame - importing GL - very bad...

On 01/02/2013 09:09 AM, someone wrote:
> On 01/02/2013 01:07 PM, Peter Otten wrote:
>> someone wrote:
>>
>>> On 01/01/2013 01:56 PM, Peter Otten wrote:
>>
>>>> from module import * # pylint: disable=W0622
>>>
>>> Oh, I just learned something new now... How come I cannot type
>>> "#pylint:
>>> enable=W0622" in the line just below the import ?
>>
>> With what intended effect?
>
> If I have a section with A LOT OF warnings and I don't want those in
> that section to show up ? Isn't that valid enough?
>
>>> Another thing is that I don't understand this warning:
>>>
>>> Invalid name "original_format" (should match (([A-Z_][A-Z0-9_]*)|
>>>   > (__.*__))$)
>>>
>>> I get it everywhere... I don't understand how it wants me to label my
>>> variables... Maybe I should disable this warning to get rid of it...
>>
>> 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.  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
of it as a pylint problem, but as a hint from pylint that perhaps you
should use fewer globals.



-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#36015 — Re: pylint, was Re: pygame - importing GL - very bad...

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

[toc] | [prev] | [next] | [standalone]

#36017 — Re: pylint, was Re: pygame - importing GL - very bad...

On Wed, Jan 2, 2013 at 4:52 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> If pylint says that global variables should be named like "__variable__",
> that is explicitly going against PEP 8.

It doesn't say that anywhere.  It includes dunder names in the regex
so that you don't get spurious warnings from pylint about the
formatting of names like __all__, nothing more.

[toc] | [prev] | [next] | [standalone]

#36021 — Re: pylint, was Re: pygame - importing GL - very bad...

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

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

[toc] | [prev] | [next] | [standalone]

#36027 — Re: pylint, was Re: pygame - importing GL - very bad...

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

[toc] | [prev] | [next] | [standalone]

#36028 — Re: pylint, was Re: pygame - importing GL - very bad...

On Wed, Jan 2, 2013 at 7:24 PM, someone <newsboost@gmail.com> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#36050 — Re: pylint, was Re: pygame - importing GL - very bad...

On 01/03/2013 03:55 AM, Ian Kelly wrote:
> On Wed, Jan 2, 2013 at 7:24 PM, someone <newsboost@gmail.com> wrote:

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

[toc] | [prev] | [next] | [standalone]

#36052 — Re: pylint, was Re: pygame - importing GL - very bad...

On Thu, Jan 3, 2013 at 10:19 PM, someone <newsboost@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#36144 — Re: pylint, was Re: pygame - importing GL - very bad...

On 01/03/2013 12:27 PM, Chris Angelico wrote:
> On Thu, Jan 3, 2013 at 10:19 PM, someone <newsboost@gmail.com> wrote:
>> 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.

Got it, thanks!

[toc] | [prev] | [next] | [standalone]

#36164 — Re: pylint, was Re: pygame - importing GL - very bad...

On 05.01.2013 03:11, someone wrote:
> On 01/03/2013 12:27 PM, Chris Angelico wrote:
>> On Thu, Jan 3, 2013 at 10:19 PM, someone <newsboost@gmail.com> wrote:
>>> 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.
>
> Got it, thanks!
>
>

Just following the discussion which is very interesting, even so when 
not working with OpenGL (which looks like a nightmare with that naming 
space) :)

But about the regular expressions (a bit deeper look into that):
Like said of Chris:

[a-z]
defines a "catching group", in this case all ascii lowercase letters 
ranging from "a" to "z". If noting else is provided, the rule matches 
one letter if there is no range defined by something like:
{} -> Target a range of a match/hit

There are also a
? -> Lazy match
* -> Gready match

[A-Z][0-9]{1,3} means translated:
Look for any uppercase letter in ascii(!) (not "öäü" or similiar) 
ranging from "A" to "Z".

Now look for any digit (2nd catching group) with the addition to satisfy 
the rule ONLY if there are at least 1 to 3 digits found.
Note: If there are 4 or more digits - the catching rule is still 
satisfied and will provide a match/hit.

If there is a follow up group, the next evaluation is gone through if 
present and so forth. If the expression is satisfied, the match is returned.

The lazy "?" and greedy "*" matches try to satisfy, as the naming 
implies, to match as less or as much of what you have asked for.

For example the regular expression is valid:
0* -> Look for a zero, and be greedy as of how many zeros you want match 
which might follow.

Regular expressions don't have to include catching groups in order to work.

But when you use them yourself somehow, its quite simple I think.
I guess you are anyhow busy mangling with pyLint, PEP-Standards and 
pyOpenGL - so good luck with that :)

Jan Riechers

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web