Re: pygame - importing GL - very bad...
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 :)
--
http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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
Re: pygame - importing GL - very bad...
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... -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
On Sat, Jan 5, 2013 at 9:49 PM, someone newsbo...@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 -- http://mail.python.org/mailman/listinfo/python-list
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 newsbo...@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
--
http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 01/05/2013 01:49 PM, Jan Riechers wrote:
On 05.01.2013 03:11, someone wrote:
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.
Ok, thanks a lot for the elaboration... I think I need to work with it
myself at some time to be sure of understanding it...
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 :)
You're right - I'm a bit overbooked at the moment - but thanks a lot
for clarifyring this with the regexps :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
On Sun, Jan 6, 2013 at 12:06 AM, someone newsbo...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
On 01/05/2013 02:27 PM, Chris Angelico wrote: On Sun, Jan 6, 2013 at 12:06 AM, someone newsbo...@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... -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 01/03/2013 05:52 PM, Terry Reedy wrote: That seems like a improper error message from the tool. Invalid name does *not* properly describe that situation. The name is *not* Invalid in any sense of the word, and a checker that tells you it is is creating needless false-positives. An error checker should be saying something like: self.lightDone: Does not match PEP8 recommended style making it clear that this is *not* an error, it is a *style* related *warning*. I quite agree. Wanting 3 chars for attribute names is not even PEP-8 style but pylint-author style. I was really surprised at that. In that case, 'Does not match pylint recommended style.' or even 'configured styles'. I have not used pylint or pychecker as of yet. I agree with you all... Thanks, everyone - now I shall investigate pylint and friends in more detail on my own :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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... -- http://mail.python.org/mailman/listinfo/python-list
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 newsbo...@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!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Regular expression syntax, was Re: pylint, was Re: pygame - importing GL - very bad...
On 01/03/2013 12:39 PM, Peter Otten wrote:
someone wrote:
On 01/03/2013 10:00 AM, Peter Otten wrote:
Terry Reedy wrote:
[a-z_][a-z0-9_]{2,30}$) - so I suppose it wants this name to end with
[an
underscore ?
No, it allows underscores. As I read that re, 'rx', etc, do match. They
No, it's one leading letter or underscore [a-z_] plus at least two
letters, underscores or digits [a-z0-9_]{2,30}
Ah, [a-z0-9_]{2,30} means there should be at least two characters and
maximum 30 characters here ?
Yes. See
http://docs.python.org/2/library/re.html#regular-expression-syntax
Thanks - it's on my TODO-list to learn more about how to use these
regexps...
--
http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 01/03/2013 03:56 AM, Dave Angel wrote: The first lint program I recall hearing of was available in the early 1980's, and was for the C language. At the time, the C language was extremely flexible (in other words, lots of ways to shoot yourself in the foot) and the compiler was mostly of the philosophy - if there's a way to make sense of the statement, generate some code, somehow. Anyway, lint made sense to me as the crud that gets mixed in with the real fabric. And a linter is a machine that identifies and removes that crud. Well, the lint program didn't remove anything, but it identified a lot of it. I didn't hear the term linter till decades later. Aah, now I understand this lintering and where it came from - thanks a lot! :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
Terry Reedy wrote:
[a-z_][a-z0-9_]{2,30}$) - so I suppose it wants this name to end with an
underscore ?
No, it allows underscores. As I read that re, 'rx', etc, do match. They
No, it's one leading letter or underscore [a-z_] plus at least two letters,
underscores or digits [a-z0-9_]{2,30}
--
http://mail.python.org/mailman/listinfo/python-list
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 newsbo...@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...
--
http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 01/03/2013 10:00 AM, Peter Otten wrote:
Terry Reedy wrote:
[a-z_][a-z0-9_]{2,30}$) - so I suppose it wants this name to end with an
underscore ?
No, it allows underscores. As I read that re, 'rx', etc, do match. They
No, it's one leading letter or underscore [a-z_] plus at least two letters,
underscores or digits [a-z0-9_]{2,30}
Ah, [a-z0-9_]{2,30} means there should be at least two characters and
maximum 30 characters here ?
--
http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Thu, Jan 3, 2013 at 10:19 PM, someone newsbo...@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
--
http://mail.python.org/mailman/listinfo/python-list
Regular expression syntax, was Re: pylint, was Re: pygame - importing GL - very bad...
someone wrote:
On 01/03/2013 10:00 AM, Peter Otten wrote:
Terry Reedy wrote:
[a-z_][a-z0-9_]{2,30}$) - so I suppose it wants this name to end with
[an
underscore ?
No, it allows underscores. As I read that re, 'rx', etc, do match. They
No, it's one leading letter or underscore [a-z_] plus at least two
letters, underscores or digits [a-z0-9_]{2,30}
Ah, [a-z0-9_]{2,30} means there should be at least two characters and
maximum 30 characters here ?
Yes. See
http://docs.python.org/2/library/re.html#regular-expression-syntax
--
http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 13-01-02 09:48 PM, Terry Reedy wrote:
...
2) self.lightDone: Invalid name lightDone (should match
[a-z_][a-z0-9_]{2,30}$)
So I can now understand that pylint doesn't like my naming convention
with a capital letter in the middle of the variable name, like:
lightDone = a boolean value. I suppose pylint wants me to use (a
little longer method) an underscore to separate words in long variable
names...
That is more conventional in the Python community (and is in pep 8, I
believe) but still a choice.
That seems like a improper error message from the tool. Invalid name
does *not* properly describe that situation. The name is *not*
Invalid in any sense of the word, and a checker that tells you it is
is creating needless false-positives. An error checker should be saying
something like:
self.lightDone: Does not match PEP8 recommended style
making it clear that this is *not* an error, it is a *style* related
*warning*.
HTH,
Mike
--
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 1/3/2013 9:19 AM, Mike C. Fletcher wrote:
On 13-01-02 09:48 PM, Terry Reedy wrote:
...
2) self.lightDone: Invalid name lightDone (should match
[a-z_][a-z0-9_]{2,30}$)
So I can now understand that pylint doesn't like my naming convention
with a capital letter in the middle of the variable name, like:
lightDone = a boolean value. I suppose pylint wants me to use (a
little longer method) an underscore to separate words in long variable
names...
That is more conventional in the Python community (and is in pep 8, I
believe) but still a choice.
That seems like a improper error message from the tool. Invalid name
does *not* properly describe that situation. The name is *not*
Invalid in any sense of the word, and a checker that tells you it is
is creating needless false-positives. An error checker should be saying
something like:
self.lightDone: Does not match PEP8 recommended style
making it clear that this is *not* an error, it is a *style* related
*warning*.
I quite agree. Wanting 3 chars for attribute names is not even PEP-8
style but pylint-author style. I was really surprised at that. In that
case, 'Does not match pylint recommended style.' or even 'configured
styles'. I have not used pylint or pychecker as of yet.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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_ :) -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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) :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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. :-) -- http://mail.python.org/mailman/listinfo/python-list
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... -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Wed, Jan 2, 2013 at 11:07 PM, Peter Otten __pete...@web.de wrote: someone wrote: 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 Okay, I have to ask... why? Does it have an exception for names of classes? I don't like linters that enforce too much style. Catch things that might be mis-coded (like C's classic if (x = 1)), but don't complain about my names. They're MY business. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Wed, Jan 2, 2013 at 7:32 AM, Chris Angelico ros...@gmail.com wrote: Okay, I have to ask... why? Does it have an exception for names of classes? Yes, and for module-level functions. I don't like linters that enforce too much style. Catch things that might be mis-coded (like C's classic if (x = 1)), but don't complain about my names. They're MY business. pylint is configurable though, so you can disable any warnings you don't care about. My pylint macro has a fairly large number of -d options in it. -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Thu, Jan 3, 2013 at 4:52 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Jan 2, 2013 at 7:32 AM, Chris Angelico ros...@gmail.com wrote: Okay, I have to ask... why? Does it have an exception for names of classes? Yes, and for module-level functions. Oh, okay. So the check's a lot more specific than the message implies - it applies only to non-callable module level names. I guess that's reasonable. I don't like linters that enforce too much style. Catch things that might be mis-coded (like C's classic if (x = 1)), but don't complain about my names. They're MY business. pylint is configurable though, so you can disable any warnings you don't care about. My pylint macro has a fairly large number of -d options in it. Yeah, same applies to most linters I think. You end up disagreeing with the author on half the points. Oh well. Doesn't make the tool useless, just means you need to fiddle with it to get it how you want it. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Wed, Jan 2, 2013 at 10:57 AM, Chris Angelico ros...@gmail.com wrote: Yeah, same applies to most linters I think. You end up disagreeing with the author on half the points. Oh well. Doesn't make the tool useless, just means you need to fiddle with it to get it how you want it. It's a lot less work to disable a check than to implement a desired check that is missing, so to me it's better that a linter do too much by default than not enough. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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 -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Wed, Jan 2, 2013 at 4:52 PM, Steven D'Aprano steve+comp.lang.pyt...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 01/02/2013 03:26 PM, Dave Angel wrote: On 01/02/2013 09:09 AM, someone wrote: On 01/02/2013 01:07 PM, Peter Otten wrote: OMG... I don't want to type those underscores everywhere... Anyway, thank you very much for explaining the meaning of what it wants... Global const values should be ALL_CAPS, so it's obvious that nobody intends to modify them. It's the non-const global attributes that expect to be underscored. You shouldn't have to use those underscores very often. After all, there is seldom a need for a non-const global value, right? Don't think I suppose you're right. of it as a pylint problem, but as a hint from pylint that perhaps you should use fewer globals. I had some bad code which I improved greatly now with thanks to pylint. I'll remember what you've written the next time I look at it - I think I don't use that many global non-const values now - I wrapped a lot of things into a class now. This is much better and I guess the correct object-oriented thing to do. I hope/think I'll get this warning a lot fewer times in the future. Thanks a lot for the explanation. -- http://mail.python.org/mailman/listinfo/python-list
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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 01/02/2013 08:31 PM, Ian Kelly wrote: On Wed, Jan 2, 2013 at 10:57 AM, Chris Angelico ros...@gmail.com wrote: Yeah, same applies to most linters I think. You end up disagreeing with the author on half the points. Oh well. Doesn't make the tool useless, just means you need to fiddle with it to get it how you want it. It's a lot less work to disable a check than to implement a desired check that is missing, so to me it's better that a linter do too much by default than not enough. I just started using pylint and some of the stuff it came up with is REALLY good - so I'll definately use pylint, pep8 (and friends) more in the future. And I think I'll also get to a point where I'll disable some of the checks - as one of you wrote: How I name my variables is (maybe) my own business and for instance I like a short variable name once in a while, e.g. rx, ry, rz for rotation around x- y- and z-axises and these variable names should not be changed. But can I ask you something: English is not my native language and I looked up what linter means - but it's not in my dictionary. What doet linter mean ? I don't suppose these exlanations are the same as you would give, in the context you're using? http://www.wordreference.com/definition/linter http://www.collinsdictionary.com/dictionary/american/linter http://www.merriam-webster.com/dictionary/linter ? -- http://mail.python.org/mailman/listinfo/python-list
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Wed, Jan 2, 2013 at 7:24 PM, someone newsbo...@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.
--
http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On 01/02/2013 09:31 PM, someone wrote: On 01/02/2013 08:31 PM, Ian Kelly wrote: On Wed, Jan 2, 2013 at 10:57 AM, Chris Angelico ros...@gmail.com wrote: Yeah, same applies to most linters I think. You end up disagreeing with the author on half the points. Oh well. Doesn't make the tool useless, just means you need to fiddle with it to get it how you want it. It's a lot less work to disable a check than to implement a desired check that is missing, so to me it's better that a linter do too much by default than not enough. I just started using pylint and some of the stuff it came up with is REALLY good - so I'll definately use pylint, pep8 (and friends) more in the future. And I think I'll also get to a point where I'll disable some of the checks - as one of you wrote: How I name my variables is (maybe) my own business and for instance I like a short variable name once in a while, e.g. rx, ry, rz for rotation around x- y- and z-axises and these variable names should not be changed. But can I ask you something: English is not my native language and I looked up what linter means - but it's not in my dictionary. What doet linter mean ? I don't suppose these exlanations are the same as you would give, in the context you're using? http://www.wordreference.com/definition/linter http://www.collinsdictionary.com/dictionary/american/linter http://www.merriam-webster.com/dictionary/linter ? The first lint program I recall hearing of was available in the early 1980's, and was for the C language. At the time, the C language was extremely flexible (in other words, lots of ways to shoot yourself in the foot) and the compiler was mostly of the philosophy - if there's a way to make sense of the statement, generate some code, somehow. Anyway, lint made sense to me as the crud that gets mixed in with the real fabric. And a linter is a machine that identifies and removes that crud. Well, the lint program didn't remove anything, but it identified a lot of it. I didn't hear the term linter till decades later. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
Ian Kelly ian.g.ke...@gmail.com writes: On Wed, Jan 2, 2013 at 7:24 PM, someone newsbo...@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. PEP 8 discourages camelCase for names except for compatibility purposes, and recommends TitleCase for class names. -- \ “I'm having amnesia and déjà vu at the same time. I feel like | `\ I've forgotten this before sometime.” —Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint, was Re: pygame - importing GL - very bad...
On Wed, Jan 2, 2013 at 10:01 PM, Ben Finney ben+pyt...@benfinney.id.au wrote: Ian Kelly ian.g.ke...@gmail.com writes: On Wed, Jan 2, 2013 at 7:24 PM, someone newsbo...@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. PEP 8 discourages camelCase for names except for compatibility purposes, and recommends TitleCase for class names. If we must quibble over meta-nomenclature... http://www.python.org/dev/peps/pep-0008/ : The following naming styles are commonly distinguished: [...] * CapitalizedWords (or CapWords, or CamelCase -- so named because of the bumpy look of its letters [3]). […] * mixedCase (differs from CapitalizedWords by initial lowercase character!) The term TitleCase does not make an appearance in the document. Regards, Chris -- http://mail.python.org/mailman/listinfo/python-list
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
On Tue, Jan 1, 2013 at 10:00 PM, someone newsbo...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
On Jan 1, 9:00 pm, someone newsbo...@gmail.com wrote: I can see that pygame hasn't been updated for a long while - not many users use it? It helps if you look in the right place: pygame Last Updated 2012-12-29: https://bitbucket.org/pygame/pygame/src pygame2: http://code.google.com/p/pgreloaded/ -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
On 01/01/2013 12:13 PM, Chris Angelico wrote: On Tue, Jan 1, 2013 at 10:00 PM, someone newsbo...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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... -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
On 01/01/2013 11:39 PM, alex23 wrote: On Jan 1, 9:00 pm, someone newsbo...@gmail.com wrote: I can see that pygame hasn't been updated for a long while - not many users use it? It helps if you look in the right place: pygame Last Updated 2012-12-29: https://bitbucket.org/pygame/pygame/src pygame2: http://code.google.com/p/pgreloaded/ Maybe... But if you look for stable releases here: http://www.pygame.org/download.shtml You'll find the top option: 1.9.1 Packages (August 6th 2009) And then previous releases is just below 1.9.1: pygame-1.9.0release.tar.gz ~ 1.4M - August 1, 2009 pygame-1.8.1release.tar.gz ~ 1.4M - July 30, 2008 pygame-1.8.0release.tar.gz ~ 1.4M - March 29, 2008 pygame-1.7.1release.tar.gz ~ 1.3M - August 16, 2005 1.7.0 ~ no source release was made. pygame-1.6.2.tar.bz2 ~ 1140 kb - pygame-1.6.tar.gz ~ 832 kb - October 23, 2003 pygame-1.5.tar.gz ~ 736 kb - May 30, 2002 pygame-1.4.tar.gz ~ 808 kb - Jan 30, 2002 pygame-1.3.tar.gz ~ 731 kb - Dec 19, 2001 pygame-1.2.tar.gz ~ 708 kb - Sep 4, 2001 pygame-1.1.tar.gz ~ 644 kb - Jun 23, 2001 pygame-1.0.tar.gz ~ 564 kb - Apr 5, 2001 pygame-0.9.tar.gz ~ 452 kb - Feb 13, 2001 pygame-0.5.tar.gz ~ 436 kb - Jan 6 14, 2001 pygame-0.4.tar.gz ~ 420 kb - Dec 14, 2000 pygame-0.3b.tar.gz ~ 367 kb - Nov 20, 2000 pygame-0.2b.tar.gz ~ 408 kb - Nov 3, 2000 pygame-0.1a.tar.gz ~ 300 kb - Oct 28, 2000 Back to year 2000... Maybe they should get a grip on themselves and distribute a new stable releases in year 2013 - then it would at least SEEM to look as the project is not dead. But in any case, I'm happy with it - haven't experienced any big issues with pygame yet, so don't take this as I don't value what they do. Maybe they've made a great version back in 2009 and it's so good that there wasn't any need for a newer stable version before 2013. But it gives the impression that nothing happens, when so many years pass on... Anyway, thanks a lot to all... (And sorry I accidentally replied privately to some of you - in thunderbird I should hit the followup-button but maybe they've removed it and instead I keep on hitting reply - very confusing that the first button in thunderbird is reply instead of followup, which is what I always prefer to use (so other people can see the answers). Thanks you for pointing out that (at least) something did happen on 2012-12-29, when it looks a bit dead on the official homepage. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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! -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame - importing GL - very bad...
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 -- http://mail.python.org/mailman/listinfo/python-list
