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 1 of 3  [1] 2 3  Next page →

#35882 — pygame - importing GL - very bad...

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.

[toc] | [next] | [standalone]

#35883

On Tue, Jan 1, 2013 at 10:00 PM, someone <newsboost@gmail.com> 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
>
> Any good / clever solution to this problem, so I avoid this nasty crappy
> work-around?

You could simply

import OpenGL.GL as GL

and then use all those names as GL.glPopMatrix, GL.GL_LIGHTING, etc. I
don't know if that's better or worse.

ChrisA

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

#35930

On 01/01/2013 12:13 PM, Chris Angelico wrote:
 > On Tue, Jan 1, 2013 at 10:00 PM, someone <newsboost@gmail.com> 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
 >>
 >> Any good / clever solution to this problem, so I avoid this nasty crappy
 >> work-around?
 >
 > You could simply
 >
 > import OpenGL.GL as GL
 >
 > and then use all those names as GL.glPopMatrix, GL.GL_LIGHTING, etc. I
 > don't know if that's better or worse.

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

Thank you.

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

#36011

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.

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

#36018

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.

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

#36060

On 13-01-02 08:53 PM, someone wrote:
> 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.
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

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

#36143

On 01/03/2013 03:09 PM, Mike C. Fletcher wrote:
> On 13-01-02 08:53 PM, someone wrote:

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

Good to hear, I'm not alone, thanks.

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

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?

> 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

Agree - that's something I like.

> from C OpenGL, making the API look entirely different wouldn't be a good
> direction to move, IMO.

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

Thanks for the comments about this transitional opengl-stuff - I was 
unaware of that. Currently it's not so interesting to me, I like it the 
way I do it now so I can quickly grab code pieces from C/C++ from the 
web and change it to suit my needs...

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

#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

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

#36156

On 01/05/2013 02:30 AM, Dave Angel wrote:
>>> 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.

Ah, you're right. Sorry :-)

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

Ok, I think you're right. At least I find that C-compilers catches many 
errors/warnings which python don't say anything about. But also C 
require me to define/declarer the types of variables before I use 
them... OTOH I guess I like that python is faster to code in, compared 
to C...

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

Ok, I'll look forward to that. Recently I had some problems with 
pass-by-value vs pass-by-reference. I googled the problem and found that 
by default python passes by reference. I then debugged my program and 
finally found out that I should make a copy (a new object) of the 
variable, before I passed it to my function. And THIS solved my problem. 
But in C/C++ I think the default is to pass by value, so this error in 
my program was a bit unexpected... Anyway, I feel python is a great 
language for doing things much faster than I could possibly do in C/C++.

I also have on my todo-list to take my opengl-program and make it into 
an executable. I mainly sit on a linux-pc but I want to distribute my 
opengl program for windows (which has most users). I've found something 
on google for py2app, cx_Freeze, bbfreeze and Freeze and I hope this 
cross-platform thing does not cause too many problems... I tried one of 
these tools a few weeks ago but I think I only succeeded with a very 
simple hello-world program... Anyway, that's a problem I'll investigate 
in a few months when I think/hope my opengl program is finished...

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

#36157

On 01/05/2013 05:49 AM, someone wrote:
> On 01/05/2013 02:30 AM, Dave Angel wrote:
>
<snip>
>>
>> Function objects are enormously useful, as you get more adept at using
>> Python.
>
> Ok, I'll look forward to that. Recently I had some problems with
> pass-by-value vs pass-by-reference. I googled the problem and found
> that by default python passes by reference.

Pascal has two calling conventions (value and reference).  C always
calls by value.  C++ adds a call by reference, and maybe later C
standards have added it as well.

Python always calls by object.  In fact, one could argue that there are
no values (in the C sense) in Python.  All names, and all attributes,
and all slots in collections, are references to objects.  So when you
call a function, what you're doing is telling the function how to
reference the same object(s).  The usual way to say that is that the
function call binds a new name to an existing object.

If that object is mutable, then perhaps you wanted to do a copy first. 
Or perhaps you didn't.  As you say, you debugged the program to find out.

> I then debugged my program and finally found out that I should make a
> copy (a new object) of the variable, before I passed it to my
> function. And THIS solved my problem. But in C/C++ I think the default
> is to pass by value, so this error in my program was a bit
> unexpected... Anyway, I feel python is a great language for doing
> things much faster than I could possibly do in C/C++.
>
> I also have on my todo-list to take my opengl-program and make it into
> an executable. I mainly sit on a linux-pc but I want to distribute my
> opengl program for windows (which has most users). I've found
> something on google for py2app, cx_Freeze, bbfreeze and Freeze and I
> hope this cross-platform thing does not cause too many problems... I
> tried one of these tools a few weeks ago but I think I only succeeded
> with a very simple hello-world program... Anyway, that's a problem
> I'll investigate in a few months when I think/hope my opengl program
> is finished...
>


-- 

DaveA

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

#36159

On Sat, Jan 5, 2013 at 9:49 PM, someone <newsboost@gmail.com> wrote:
> Ok, I think you're right. At least I find that C-compilers catches many
> errors/warnings which python don't say anything about. But also C require me
> to define/declarer the types of variables before I use them... OTOH I guess
> I like that python is faster to code in, compared to C...

C has typed variables, so it's a compile-time error to try to put any
other type into that variable. Python doesn't. That flexibility comes
at the cost of error-catching. There are hybrid systems, but in
general, type declarations imply variable declarations, and that's
something that Python doesn't want. (I'm of the opinion that
declarations aren't such a bad thing; they make some aspects of
scoping easier. However, that's a design decision that Python is as
unlikely to reverse as indentation-defined blocks.)

> Ok, I'll look forward to that. Recently I had some problems with
> pass-by-value vs pass-by-reference. I googled the problem and found that by
> default python passes by reference.

No, it doesn't. You can find good references on the subject in various
places, but call-by-reference as implemented in Pascal simply doesn't
exist in most modern languages, because its semantics are way
confusing. The name given to this technique varies; here's a couple of
links:

http://effbot.org/zone/call-by-object.htm
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing

ChrisA

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

#36165

On 01/05/2013 12:47 PM, Chris Angelico wrote:
> C has typed variables, so it's a compile-time error to try to put any
> other type into that variable. Python doesn't. That flexibility comes
> at the cost of error-catching. There are hybrid systems, but in
> general, type declarations imply variable declarations, and that's
> something that Python doesn't want. (I'm of the opinion that
> declarations aren't such a bad thing; they make some aspects of
> scoping easier. However, that's a design decision that Python is as
> unlikely to reverse as indentation-defined blocks.)

Understood.

>> Ok, I'll look forward to that. Recently I had some problems with
>> pass-by-value vs pass-by-reference. I googled the problem and found that by
>> default python passes by reference.
>
> No, it doesn't. You can find good references on the subject in various
> places, but call-by-reference as implemented in Pascal simply doesn't
> exist in most modern languages, because its semantics are way
> confusing. The name given to this technique varies; here's a couple of
> links:
>
> http://effbot.org/zone/call-by-object.htm
> http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing

If you don't like calling it "pass-by-reference", perhaps you prefer 
calling it: “call by object reference“...  From: 
http://effbot.org/zone/call-by-object.htm

In any case I think we understand each other.

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

#36168

On Sun, Jan 6, 2013 at 12:06 AM, someone <newsboost@gmail.com> wrote:
> On 01/05/2013 12:47 PM, Chris Angelico wrote:
>> You can find good references on the subject in various
>> places, but call-by-reference as implemented in Pascal simply doesn't
>> exist in most modern languages, because its semantics are way
>> confusing. The name given to this technique varies; here's a couple of
>> links:
>>
>> http://effbot.org/zone/call-by-object.htm
>> http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing
>
> If you don't like calling it "pass-by-reference", perhaps you prefer calling
> it: “call by object reference“...  From:
> http://effbot.org/zone/call-by-object.htm
>
> In any case I think we understand each other.

That's one of the links I just posted :) It's not just a naming
difference, though. With Pascal's pass-by-reference semantics, this
code would act differently:

def foo(x):
  x = 5

a = 2
foo(a)
print(a)

Python prints 2, because the assignment to x just rebinds the name
inside foo. True pass-by-reference actually changes the caller's
variable. C can achieve this by means of pointers; in Python, you can
pass and mutate a list, thus:

def foo(x):
  x[0] = 5 # Dereference the pointer, kinda

x=[None] # Declare a pointer variable, ish
x[0] = 2
foo(x) # Don't forget to drop the [0] when passing the pointer to
another function
print(x[0]) # Prints 5. See? We have pass-by-reference!

But otherwise, rebinding names in the function has no effect on
anything outside. Among other things, this guarantees that, in any
situation, a name referencing an object can be perfectly substituted
for any other name referencing the same object, or any other way of
accessing the object.

def foo(lst):
  lst[0]=len(lst)

x = [10,20,30]
y = x
foo(x) # These two...
foo(y) # ... are identical!

This is a philosophy that extends through the rest of the language. A
function returning a list can be directly dereferenced, as can a list
literal:

def foo():
  return [0,1,4,9,16]

print( ["Hello","world!","Testing","Testing","One","Two","Three"][foo()[2]] )

This is a flexibility and power that just doesn't exist in many older
languages (C and PHP, I'm looking at you). Object semantics make more
sense than any other system for a modern high level language, which is
why many of them do things that way.

ChrisA

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

#36202

On 01/05/2013 02:27 PM, Chris Angelico wrote:
> On Sun, Jan 6, 2013 at 12:06 AM, someone <newsboost@gmail.com> wrote:

>> In any case I think we understand each other.
>
> That's one of the links I just posted :) It's not just a naming
> difference, though. With Pascal's pass-by-reference semantics, this
> code would act differently:
>
> def foo(x):
>    x = 5
>
> a = 2
> foo(a)
> print(a)
>
> Python prints 2, because the assignment to x just rebinds the name
> inside foo. True pass-by-reference actually changes the caller's
> variable. C can achieve this by means of pointers; in Python, you can

I thought that python also used "true" pass-by-reference, although I 
haven't figured out exactly when I have this problem. I can just see 
that sometimes I get this problem and then I need to copy the variable, 
if I don't want the original data of the variable to be overwritten...

> pass and mutate a list, thus:
>
> def foo(x):
>    x[0] = 5 # Dereference the pointer, kinda
>
> x=[None] # Declare a pointer variable, ish
> x[0] = 2
> foo(x) # Don't forget to drop the [0] when passing the pointer to
> another function
> print(x[0]) # Prints 5. See? We have pass-by-reference!

Yes, something like this has happened to me in my python code... Not 
sure if my example was exactly like this, but I remember something where 
I found this to be a problem that I had to fix.

> But otherwise, rebinding names in the function has no effect on
> anything outside. Among other things, this guarantees that, in any

hmm. ok.... So it's not true pass-by-reference like I thought... That's 
interesting.

> situation, a name referencing an object can be perfectly substituted
> for any other name referencing the same object, or any other way of
> accessing the object.
>
> def foo(lst):
>    lst[0]=len(lst)
>
> x = [10,20,30]
> y = x
> foo(x) # These two...
> foo(y) # ... are identical!

This is something I've experienced from my own coding, I think...

> This is a philosophy that extends through the rest of the language. A
> function returning a list can be directly dereferenced, as can a list
> literal:
>
> def foo():
>    return [0,1,4,9,16]
>
> print( ["Hello","world!","Testing","Testing","One","Two","Three"][foo()[2]] )

That prints out "One"... I think I understand - that's interesting too...

> This is a flexibility and power that just doesn't exist in many older
> languages (C and PHP, I'm looking at you). Object semantics make more
> sense than any other system for a modern high level language, which is
> why many of them do things that way.

I agree, that I think python is really great and it's fast to do 
something useful. Not sure I still understand exactly all aspects of 
this pass-by-value and by-references, but in any case I know enough to 
watch out for this problem and once I see I have a problem, I can also 
take care of it and solve it by making a copy. I think maybe after 3-6-9 
months more of working with python, I should be fully confident with 
this. Thanks for taking the time to explain a bit of this to me...

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

#36234

On Jan 6, 5:49 am, someone <newsbo...@gmail.com> wrote:
> I thought that python also used "true" pass-by-reference, although I
> haven't figured out exactly when I have this problem. I can just see
> that sometimes I get this problem and then I need to copy the variable,
> if I don't want the original data of the variable to be overwritten...

Generally I find it easier to call variables 'labels' or 'references';
you're not stashing a value into a slot, you're giving a name to an
object. So you're never really passing values around, just labels that
refer to an object.

The confusion kicks in because there are two types of object: mutable
and immutable. Mutable objects can change, immutable objects cannot.
Operations on an immutable object will return a _new_ immutable
object; the label used in an operation on an immutable object will
refer to the new object, any other references to the original object
will continue to refer to the original. Strings, numbers, tuples and
frozensets are all immutable built-in types.

    >>> a = "alpha"
    >>> b = a
    >>> a = a + "bet"
    >>> a
    'alphabet'
    >>> b
    'alpha'

With immutable types, you're safe to pass them into a function, act on
them, and not have references in the outer scope reflect the change:

    >>> def double(x): return x * 2
    ...
    >>> a = "alpha"
    >>> double(a)
    'alphaalpha'
    >>> a
    'alpha'

Everything else, including user defined objects, tend to be mutable:

    >>> a = dict(foo=1,bar=2)
    >>> b = a
    >>> a['foo'] = 99
    >>> a
    {'foo': 99, 'bar': 2}
    >>> b
    {'foo': 99, 'bar': 2}

With mutable objects, you're _always_ operating on the _same_ object
that everything is referring to, even when you pass it into a
different scope:

    >>> def toggle_foo( x ): x['foo'] = not x['foo']
    ...
    >>> a = dict(foo=True)
    >>> toggle_foo(a)
    >>> a
    {'foo': False}

Note that the `toggle_foo` function doesn't return anything, nor is
the value of a re-assigned. The object that a refers to is passed into
`toggle_foo`, modified in place, and all references to it remain
pointing to the same, now modified object.

This is one of the big causes of unexpected behaviour to new Python
users, but as you get a better understanding of how Python's object
model works, you'll see it's really quite consistent and predictable.

There are a couple of ways you can ensure you're always working with a
copy of an object if you need to. For lists, the canonical way is:

    >>> a = [1,2,3]
    >>> b = a
    >>> a = [1, 2, 3]
    >>> b = a[:] # shallow copy of a
    >>> b.append(99)
    >>> b
    [1, 2, 3, 99]
    >>> a
    [1, 2, 3]

`b = a[:]` uses slice notation to create a new list that contains
everything in the original list, from start to end. This is called a
"shallow" copy; `a` and `b` both refer to _different_ lists, but the
objects within are the _same_ objects. For numbers, this isn't
important, as they're immutable. For mutable objects, however, it's
something you need to bear in mind:

    >>> a = [ [1,2], [3, 4] ] # list of lists
    >>> b = a[:]
    >>> b[0][0] = 99
    >>> b
    [[99, 2], [3, 4]]
    >>> a
    [[99, 2], [3, 4]]

So here, while `b` refers to copy of `a`, that copy contains the
_same_ list objects that `a` does, so any changes to the internal
lists will be reflected in both references, while any changes to `b`
itself won't be:

    >>> b.append([5,6])
    >>> b
    [[99, 2], [3, 4], [5, 6]]
    >>> a
    [[99, 2], [3, 4]]

This is where the `copy` module comes to the rescue, providing a
shallow copy function `copy`, as well as `deepcopy` that makes copies
of all the objects within the object:

    >>> import copy
    >>> a = [ [1,2], [3, 4] ] # list of lists
    >>> b = copy.deepcopy(a)
    >>> b[0][0] = 99
    >>> b
    [[99, 2], [3, 4]]
    >>> a
    [[1, 2], [3, 4]]

If you plan on using the `copy` module, it's worthwhile readings it
docs, as there are some nuances to it that I'm glossing over here.
TBH, I don't recall every needing to use `copy` in my code.

Hope this helps bring consistency where you currently find confusion :)

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

#36236

On 01/06/2013 12:37 PM, alex23 wrote:
> On Jan 6, 5:49 am, someone <newsbo...@gmail.com> wrote:
>> I thought that python also used "true" pass-by-reference, although I
>> haven't figured out exactly when I have this problem. I can just see
>> that sometimes I get this problem and then I need to copy the variable,
>> if I don't want the original data of the variable to be overwritten...
>
> Generally I find it easier to call variables 'labels' or 'references';
> you're not stashing a value into a slot, you're giving a name to an
> object. So you're never really passing values around, just labels that
> refer to an object.

Ok.

> The confusion kicks in because there are two types of object: mutable
> and immutable. Mutable objects can change, immutable objects cannot.

Yes, I've seen that described before.

> Operations on an immutable object will return a _new_ immutable
> object; the label used in an operation on an immutable object will
> refer to the new object, any other references to the original object
> will continue to refer to the original. Strings, numbers, tuples and
> frozensets are all immutable built-in types.
>
>      >>> a = "alpha"
>      >>> b = a
>      >>> a = a + "bet"
>      >>> a
>      'alphabet'
>      >>> b
>      'alpha'

Ok, I think I knew some of these things, however I didn't think so much 
about them before now.

> With immutable types, you're safe to pass them into a function, act on
> them, and not have references in the outer scope reflect the change:
>
>      >>> def double(x): return x * 2
>      ...
>      >>> a = "alpha"
>      >>> double(a)
>      'alphaalpha'
>      >>> a
>      'alpha'

This is exactly what I've found out happens to me some times. Until now 
I've managed to fix my problems. But it's good to remember this thing 
with immutable vs. mutable types, which was something I didn't think 
much about before. I'll think about this difference in the future, thank 
you.

> Everything else, including user defined objects, tend to be mutable:
>
>      >>> a = dict(foo=1,bar=2)
>      >>> b = a
>      >>> a['foo'] = 99
>      >>> a
>      {'foo': 99, 'bar': 2}
>      >>> b
>      {'foo': 99, 'bar': 2}

Yes, I've noticed this a lot of times in my own coding...

> With mutable objects, you're _always_ operating on the _same_ object
> that everything is referring to, even when you pass it into a
> different scope:
>
>      >>> def toggle_foo( x ): x['foo'] = not x['foo']
>      ...
>      >>> a = dict(foo=True)
>      >>> toggle_foo(a)
>      >>> a
>      {'foo': False}

Exactly, what I've also experienced a few times.

> Note that the `toggle_foo` function doesn't return anything, nor is
> the value of a re-assigned. The object that a refers to is passed into
> `toggle_foo`, modified in place, and all references to it remain
> pointing to the same, now modified object.

Yes, I notice that, thanks.

> This is one of the big causes of unexpected behaviour to new Python
> users, but as you get a better understanding of how Python's object
> model works, you'll see it's really quite consistent and predictable.

It was a bit surprising to me in the beginning - though I'm still a 
beginner (or maybe now almost an "intermediate" user), the good 
explanation you come with now wasn't something I've thought so much of 
before now. But I've clearly experienced many of the examples you write 
about here, in my own coding and I've usually been very careful about 
checking if my original object was modified un-intentionally. I think I 
can deal with this now.

> There are a couple of ways you can ensure you're always working with a
> copy of an object if you need to. For lists, the canonical way is:
>
>      >>> a = [1,2,3]
>      >>> b = a
>      >>> a = [1, 2, 3]
>      >>> b = a[:] # shallow copy of a
>      >>> b.append(99)
>      >>> b
>      [1, 2, 3, 99]
>      >>> a
>      [1, 2, 3]
>
> `b = a[:]` uses slice notation to create a new list that contains
> everything in the original list, from start to end. This is called a
> "shallow" copy; `a` and `b` both refer to _different_ lists, but the
> objects within are the _same_ objects. For numbers, this isn't

Ok, good to know.

> important, as they're immutable. For mutable objects, however, it's
> something you need to bear in mind:
>
>      >>> a = [ [1,2], [3, 4] ] # list of lists
>      >>> b = a[:]
>      >>> b[0][0] = 99
>      >>> b
>      [[99, 2], [3, 4]]
>      >>> a
>      [[99, 2], [3, 4]]
>
> So here, while `b` refers to copy of `a`, that copy contains the
> _same_ list objects that `a` does, so any changes to the internal
> lists will be reflected in both references, while any changes to `b`
> itself won't be:
>
>      >>> b.append([5,6])
>      >>> b
>      [[99, 2], [3, 4], [5, 6]]
>      >>> a
>      [[99, 2], [3, 4]]

Yes, I've experienced this kind of thing before - but it's a very very 
good explanation you give me know. It makes me understand the problem 
much better, next time I experience it...

> This is where the `copy` module comes to the rescue, providing a
> shallow copy function `copy`, as well as `deepcopy` that makes copies
> of all the objects within the object:
>
>      >>> import copy
>      >>> a = [ [1,2], [3, 4] ] # list of lists
>      >>> b = copy.deepcopy(a)
>      >>> b[0][0] = 99
>      >>> b
>      [[99, 2], [3, 4]]
>      >>> a
>      [[1, 2], [3, 4]]
>
> If you plan on using the `copy` module, it's worthwhile readings it
> docs, as there are some nuances to it that I'm glossing over here.
> TBH, I don't recall every needing to use `copy` in my code.

I almost had to use this "copy.deepcopy" the other day, but I googled 
for it and then I found a way to avoid it...

> Hope this helps bring consistency where you currently find confusion :)

Yes, this is a VERY very good explanation. I was a bit confused about 
when I created my own user defined objects, but now you explained that 
these tend to be mutable which is also my experience.

I'll still keep an extra eye out for this special way of sending objects 
back and forward between function, in order to un-intentionally 
overwrite some data...

Thanks you very much for a very good and precise description of this 
phenomena of the python-language (or what I should call it) :-)

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

#36013

On 2013.01.02 15:57, Michael Torrie wrote:
> 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.
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
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
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).
-- 
CPython 3.3.0 | Windows NT 6.2.9200.16461

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

#36019

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.

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

#35885

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


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


-- 
Steven

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

#35931

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

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

Are you sure?

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web