Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Closures in leu of pointers?

Reply
Thread Tools

Closures in leu of pointers?

 
 
cts.private.yahoo@gmail.com
Guest
Posts: n/a
 
      06-29-2013
I love the title. Reminds me of Ivanhoe ... great time travel.
 
Reply With Quote
 
 
 
 
Antoon Pardon
Guest
Posts: n/a
 
      06-29-2013
Op 29-06-13 16:02, Michael Torrie schreef:
>
> The real problem here is that you don't understand how python variables
> work. And in fact, python does not have variables. It has names that
> bind to objects.


I don't understand why members of this list keep saying this. Sure the
variables in python behave differently than those in C and algol But
they behave similarly as those in smalltalk and lisp and I haven't seen
anyone claim that smalltalk and lisp don't have variables.

We might as well say that C doesn't have variables, it has names
pointing to memory locations or value containers or something
like that.

AFAICS there is no reason why "variable" wouldn't be appropiate
for python names as opposed to C names.

--
Antoon Pardon

 
Reply With Quote
 
 
 
 
rusi
Guest
Posts: n/a
 
      06-29-2013
On Saturday, June 29, 2013 10:32:01 PM UTC+5:30, Antoon Pardon wrote:
> Op 29-06-13 16:02, Michael Torrie schreef:
> > The real problem here is that you don't understand how python variables
> > work. And in fact, python does not have variables. It has names that
> > bind to objects.

>
> I don't understand why members of this list keep saying this. Sure the
> variables in python behave differently than those in C and algol But
> they behave similarly as those in smalltalk and lisp and I haven't seen
> anyone claim that smalltalk and lisp don't have variables.
>
> We might as well say that C doesn't have variables, it has names
> pointing to memory locations or value containers or something
> like that.
>
> AFAICS there is no reason why "variable" wouldn't be appropiate
> for python names as opposed to C names.


Well mathematicians (or to be more precise functional programmers pretending to be mathematicians) claim that any imperative language does not have variables.

And recently on this list I saw the exact opposite claim -- functional languages dont have variables.

I also remember my statistics teacher dinning it into us -- a random variable is not a variable.

So each one varies according to his own notions I guess

 
Reply With Quote
 
Michael Torrie
Guest
Posts: n/a
 
      06-29-2013
On 06/29/2013 11:02 AM, Antoon Pardon wrote:
> Op 29-06-13 16:02, Michael Torrie schreef:
>>
>> The real problem here is that you don't understand how python variables
>> work. And in fact, python does not have variables. It has names that
>> bind to objects.

>
> I don't understand why members of this list keep saying this. Sure the
> variables in python behave differently than those in C and algol But
> they behave similarly as those in smalltalk and lisp and I haven't seen
> anyone claim that smalltalk and lisp don't have variables.
>
> We might as well say that C doesn't have variables, it has names
> pointing to memory locations or value containers or something
> like that.


Sure but a memory location that contains say an int in C *is* a
variable, with or without a name. You can change the int stored in
that memory address at will, as part of your normal course. Python's
basic data types are immutable. At best we could say they are read-only
variables.

So no, saying Python doesn't have variables is not the same as saying C
doesn't have variables but only memory locations. They are different
concepts entirely, though on the surface they look similar.

>
> AFAICS there is no reason why "variable" wouldn't be appropiate
> for python names as opposed to C names.


Sure I see your point, but then again, calling them variables is what
led to the OP's issue in the first place. So yes they look like
variables, and for the most part act like them, except when they don't.
Hence the confusion and why I bring up the difference between python's
name binding mechanism and how a variable works. It's exactly the
concept that was tripping up the OP.
 
Reply With Quote
 
Michael Torrie
Guest
Posts: n/a
 
      06-29-2013
On 06/29/2013 07:56 AM, Michael Torrie wrote:
> x = [ 34, ]
>
> def test_func( out ):
> out[0] += 12
>
> test_func(x)
>
> print (x)


Well, actually
print (x[0])
 
Reply With Quote
 
cts.private.yahoo@gmail.com
Guest
Posts: n/a
 
      06-29-2013
Thank you guys for saying what I was biting my tongue about (thanks everybody for the help, BTW!).

This "python-think" stuff was starting to get on my nerves - but then it occurred to me that - although having many powerful features - it has so many weird restrictions that it requires a special way of thinking and problem solving.

I have to work with perl's object-orientation stuff again for awhile, in order to see if either has an advantage.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-29-2013
On Sat, 29 Jun 2013 04:21:46 -0700, cts.private.yahoo wrote:

> Thank you. You reminded me of the (weak) workaround of using arrays


I think you mean lists, rather than arrays. Python does have an array
type, but it is much more restricted.

If you want an indirect reference to a value, the simplest ways are via a
object such as a list, dict or mutable object with named attributes.
That's not really a "weak workaround". In C you would dereference a
pointer, in Python you "dereference" a list:

ptr = &obj;
value = *ptr;

becomes:

ptr[0] = obj
value = ptr[0]


although don't push the analogy too far, Python lists aren't pointers in
the C sense.

What Python doesn't have -- and it doesn't seem to me that it could have,
without support from the interpreter, is a simple way to indirectly refer
to another *name*, rather than another object.


> and
> confirmed my suspicion that I although I can read the variable, I won't
> be able to write to it. I still don't understand why not, though...


In Python 2, you simply can't because the interpreter doesn't support it.


> As for python 3 ... "nonlocal"? I see I'm not alone in picking
> obnoxious names ...


Huh?

You have "global" for global names. Python require declarations for local
names, but if it did it would probably use "local". What name would you
pick to declare names nonlocal other than "nonlocal"?


--
Steven
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-29-2013
On Sat, 29 Jun 2013 19:02:01 +0200, Antoon Pardon wrote:

> Op 29-06-13 16:02, Michael Torrie schreef:
>>
>> The real problem here is that you don't understand how python variables
>> work. And in fact, python does not have variables. It has names that
>> bind to objects.

>
> I don't understand why members of this list keep saying this. Sure the
> variables in python behave differently than those in C and algol But
> they behave similarly as those in smalltalk and lisp and I haven't seen
> anyone claim that smalltalk and lisp don't have variables.
>
> We might as well say that C doesn't have variables, it has names
> pointing to memory locations or value containers or something like that.
>
> AFAICS there is no reason why "variable" wouldn't be appropiate for
> python names as opposed to C names.


You are absolutely correct in principle. But in practice, there are ten
bazillion C, Pascal, COBOL, and BASIC programmers who understand the word
"variable" to mean a named memory location, for every Smalltalk or Lisp
programmer who understands a "variable" as a name binding. So it's pure
weight of numbers thing.

The average Lisp programmer will be completely aware that "variable" can
mean various things, and take care to determine what the word means in
Python. She will immediately grok what we mean, even if she thinks that
the "no variables" part is just an affectation ("Heh, those wacky Python
dudes think they don't have variables!") but at least she'll understand
the name binding part.

On the other hand, the average C programmer is barely aware that there
are other languages at all, let alone that some of them differ from C in
semantics as well as syntax. So by emphasising the differences ("Python
has no variables? It has name bindings?") we increase the likelihood that
he'll learn the differences in semantics as well as syntax.

So, in a very practical sense, "Python has no variables, it has name
bindings" is completely wrong except in the sense that really matters:
Python's variables don't behave identically to C variables.


--
Steven
 
Reply With Quote
 
Michael Torrie
Guest
Posts: n/a
 
      06-29-2013
On 06/29/2013 12:37 PM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Thank you guys for saying what I was biting my tongue about
> (thanks everybody for the help, BTW!).


Sometimes it's best to state the actual problem you're trying to solve
and see if there's a pythonic solution that fits it rather than to hack
a solution transliterated from C. I'm curious as to if you did get
something working and what you ended up with.

> This "python-think" stuff was starting to get on my nerves - but then
> it occurred to me that - although having many powerful features - it
> has so many weird restrictions that it requires a special way of
> thinking and problem solving.


Interesting point of view. "Pythonic" ways of programming is in my mind
the number one appeal of Python. It's quite clean yet practical. Has
enough of the intellectual purity of LISP, Smalltalk, and functional
languages to be appealing, yet the practicality of a traditional
procedural language.

In any language, though you have to grasp the data model. Usually the
criticisms of Python come from not a failure to do this, either because
it's hard to learn at first, or because people dislike learning
something different than what they are used to. A while back we had a
fairly pleasant gentleman come on the list from a C# background. His
frustrations with Python stemmed from wanting it to be like C#, which of
course it isn't. He did not have much success and I'm afraid was left
with a sour taste of Python, which of course had nothing to do with the
language itself. Python certainly has inconsistencies and there are
newbie behavioral gotchas.

> I have to work with perl's object-orientation stuff again for awhile,
> in order to see if either has an advantage.


Your original post mentioned nothing about object-orientation, so I have
no idea how you intend to use OO design, but I think you'll find
Python's model fairly workable and consistent.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-29-2013
On Sat, 29 Jun 2013 11:37:55 -0700, cts.private.yahoo wrote:

> Thank you guys for saying what I was biting my tongue about (thanks
> everybody for the help, BTW!).
>
> This "python-think" stuff was starting to get on my nerves - but then it
> occurred to me that - although having many powerful features - it has so
> many weird restrictions that it requires a special way of thinking and
> problem solving.


Er, no, you're confused. Python's restrictions aren't "weird", they make
absolutely perfect sense once you understand the programming model.
Python has a nice, clean semantic model, far cleaner than most other
languages I've looked at, which *cannot decide* on what model they wish
to present so they end up with a hodge-podge of bits of different models
all lumped together and every piece of random syntax you could ever hope
(or perhaps fear) to see.

If you insist in thinking of Python as "Perl with different syntax", then
you won't understand why you can't do certain things -- and you'll
equally not realise that you CAN do other things that other languages
don't support.


--
Steven
 
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
pointers, pointers, pointers... cerr C Programming 12 04-07-2011 11:17 PM
Does deleting a container of pointers also delete the (contained) pointers? Xamalek C++ 7 11-04-2003 04:17 PM
c++: pointers to pointers A C++ 3 10-29-2003 01:15 PM
pointers to pointers // exception handling error muser C++ 3 09-18-2003 06:19 PM
Template specialization of pointers with function pointers Phil C++ 1 09-16-2003 02:17 AM



Advertisments