Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

pygame - importing GL - very bad...

 
 
someone
Guest
Posts: n/a
 
      01-05-2013
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/Evaluat...all_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.



 
Reply With Quote
 
 
 
 
someone
Guest
Posts: n/a
 
      01-05-2013
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



 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      01-05-2013
On Sun, Jan 6, 2013 at 12:06 AM, someone <(E-Mail Removed)> 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/Evaluat...all_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
 
Reply With Quote
 
someone
Guest
Posts: n/a
 
      01-05-2013
On 01/05/2013 02:27 PM, Chris Angelico wrote:
> On Sun, Jan 6, 2013 at 12:06 AM, someone <(E-Mail Removed)> 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...


 
Reply With Quote
 
alex23
Guest
Posts: n/a
 
      01-06-2013
On Jan 6, 5:49*am, someone <(E-Mail Removed)> 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
 
Reply With Quote
 
someone
Guest
Posts: n/a
 
      01-06-2013
On 01/06/2013 12:37 PM, alex23 wrote:
> On Jan 6, 5:49 am, someone <(E-Mail Removed)> wrote:
>> I thought that python also used "true" pass-by-reference, although I
>> haven't figured out exactly when I have this problem. I can just see
>> that sometimes I get this problem and then I need to copy the variable,
>> if I don't want the original data of the variable to be overwritten...

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


Ok.

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


Yes, I've seen that described before.

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

> 'alphabet'
> >>> b

> 'alpha'


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

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

> ...
> >>> a = "alpha"
> >>> double(a)

> 'alphaalpha'
> >>> a

> 'alpha'


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

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

> {'foo': 99, 'bar': 2}
> >>> b

> {'foo': 99, 'bar': 2}


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

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

> ...
> >>> a = dict(foo=True)
> >>> toggle_foo(a)
> >>> a

> {'foo': False}


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

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


Yes, I notice that, thanks.

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


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

> There are a couple of ways you can ensure you're always working with a
> copy of an object if you need to. For lists, the canonical way is:
>
> >>> a = [1,2,3]
> >>> b = a
> >>> a = [1, 2, 3]
> >>> b = a[:] # shallow copy of a
> >>> b.append(99)
> >>> b

> [1, 2, 3, 99]
> >>> a

> [1, 2, 3]
>
> `b = a[:]` uses slice notation to create a new list that contains
> everything in the original list, from start to end. This is called a
> "shallow" copy; `a` and `b` both refer to _different_ lists, but the
> objects within are the _same_ objects. For numbers, this isn't


Ok, good to know.

> important, as they're immutable. For mutable objects, however, it's
> something you need to bear in mind:
>
> >>> a = [ [1,2], [3, 4] ] # list of lists
> >>> b = a[:]
> >>> b[0][0] = 99
> >>> b

> [[99, 2], [3, 4]]
> >>> a

> [[99, 2], [3, 4]]
>
> So here, while `b` refers to copy of `a`, that copy contains the
> _same_ list objects that `a` does, so any changes to the internal
> lists will be reflected in both references, while any changes to `b`
> itself won't be:
>
> >>> b.append([5,6])
> >>> b

> [[99, 2], [3, 4], [5, 6]]
> >>> a

> [[99, 2], [3, 4]]


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

> This is where the `copy` module comes to the rescue, providing a
> shallow copy function `copy`, as well as `deepcopy` that makes copies
> of all the objects within the object:
>
> >>> import copy
> >>> a = [ [1,2], [3, 4] ] # list of lists
> >>> b = copy.deepcopy(a)
> >>> b[0][0] = 99
> >>> b

> [[99, 2], [3, 4]]
> >>> a

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


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

> Hope this helps bring consistency where you currently find confusion


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

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

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


 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


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



Advertisments