anything like C++ references?

[Adam Ruth]

In <jkjbhvg9hcvi937ief7f1copskmogpfbmj at 4ax.com> Stephen Horne  wrote:
> On Wed, 16 Jul 2003 22:00:22 +0000 (UTC), Adam Ruth
> <owski at hotmail.com> wrote:
> 
>>In <8sdbhvk5b5ia2onmbca4ajkaidpu3ht9ed at 4ax.com> Stephen Horne  wrote:
>>> On Wed, 16 Jul 2003 19:06:40 +0000 (UTC), Adam Ruth
>>> <owski at hotmail.com> wrote:
>>> 
>>>>You are correct in that there are times when pointer semantics would 
>>>>be  somewhat useful, but they're never necessary.  His statement was 
>>>>that  there are time that "you really can't avoid pointers".
>>> 
>>> Hmmm - those words were in a context. I never claimed that "you 
>>> really can't avoid pointers" in *current* Python - that's obviously 
>>> not true. But if the copy-on-write stuff were implemented, the need 
>>> would arise. For example...
>>
>>It sure seemed that way to me:
>>
>><prior dicussion>
>>>>They're an unhappy necessity, akin to stop-lights.  You need them
>>>>because roads intersect, but if roads don't intersect, don't use 
>>>>them!
>>>
>>>Absolutely true. And the worst thing you can do when you really can't
>>>avoid pointers is to obscure the issue even more by disguising them 
>>>as something else.
>></prior discussion>
> 
> Right - "the worst thing you can do when you really can't avoid
> pointers" is not the same as "really can't avoid pointers".
> 
> You have taken the condition out of a conditional scentence and quoted
> it as if it were a statement. That's a pretty clear case of quoting
> out of context to misrepresent what someone said, isn't it.
> 
> Now lets restore the rest of what Adam said...
> 
>: I came to Python from Ada, and all I have to say is:  Pointer-like
>: semantics are evil.  They're worse than goto's, they're deadly,
>: damaging, and should be avoided at all costs.
>: 
>: They're an unhappy necessity, akin to stop-lights.  You need them
>: because roads intersect, but if roads don't intersect, don't use them!
> 
> Guess what - when Adam said pointers are an 'unhappy necessity' he was
> talking about ADA - NOT PYTHON. In Ada, pointers (or rather access
> types) are definitely not overused (where I worked you needed
> management permission and a damned good reason to use them due to the
> military contract terms), but sometimes they are unavoidable.
> 
> 
> Please be more careful what you snip.

Actually, no, I wasn't talking about Ada.  I was talking in general and 
about Pythyon.  In languages with pointers, they are there to overcome a 
weakness (the roads intersecting).  But where the roads don't intersect (
Python) there's no need to use them (or their semantics, as the case may 
be).  

So your response about diguising pointers as something else seemed to me 
to be referring to Python, since the prior message was about disguising 
a pointer as a mutable list in Pythyon.

Anyway, glad we cleared that up.  Sorry about misrepresenting you, I 
really thought you were talking about Python.  In retrospect, my 
metaphor wasn't very clear.

> 
>>The reference is passed by value 
>>to the function, just as you describe it should.
> 
> Yes - there has to be pass-by-value at some level since Python is
> implemented in C. But to me this just says that we are seeing the
> side-effect of an implementation detail.

I don't see it as a side effect, I see it as the core design.  
References are a very concrete type, they happen to be implemented as 
pointers in C.  In Java they're not implemented as pointers, I'm not 
sure what they're implemented with, but it isn't pointers.  In that case 
it must pass by reference (ala Java), but the semantics in Python of 
passing references by value is maintained.

> 
> No need to argue this - you don't need to explain it to me because I
> understand. It just see things from a different perspective.
> 
>   Python, however, has a 
>>futher layer of abstraction on top of its one data type, and that's 
>>objects.  I would venture that it's the extra layer of abstraction 
>>that  makes Python work in a more intuitive, proper way.  This is, 
>>however, just my opinion.  But it does seem that new  programmers who 
>>learn this abstraction find it natural and simple.  It's  people 
>>coming from C, et al., that seem thrown off by it.
> 
> No, my background isn't just in C - that is a long way from being the
> first language I used, and I've used Python regularly longer than C++.

I wasn't referring to you, but to the people that come to the newsgroup 
and ask questions about it.  I still don't really understand what it is 
that bugs you about it, but that's more on my end.

> 
>>As a side note, based on your description of your eduction and studies 
>>in an earlier post, I realize now how different our backgrounds seem 
>>to  be.  I'm coming from a world where the focus is engineering (Ada 
>>is the  only language purpose-built for engineering, AFAIK).  You seem 
>>to come  from a background more focused on science and theory.
> 
> Nope - I just happen to be interested in learning the theory too, and
> particularly in experiencing a broad range of languages to understand
> the ideas behind them.
> 
> How come you didn't notice ada in my list?

It's such a small word :).  I'm sure I did, but wasn't thinking in this 
context then, so I didn't INCREF the information and it got garbage 
collected.

> 
> About the first half of my programming career was working in the
> defence industry as a software engineer. A lot of that was working at
> very low level stuff (the 80c196kc microcontrollers I mentioned) and
> with a lot of messing around with target hardware and in-circuit
> emulators. The rest of my time in defence was spent using Ada.
> 
> I first messed around with writing my own language quite young, with
> an Atari ST. I liked the idea of text adventures and decided to write
> one, but basically got caught up in the engine and the scripting
> stuff. Pretty cool, though, through the rose-tinted glasses of memory.
> 
> Anyway, I stayed interested in compilers and stuff, but the reason I
> got interested in LR and parsing theory has little to do with parsing
> as most see it. A grammar, seen as describing a sequence of tokens,
> can deal with many things - the tokens don't have to be words. They
> might be events, for instance. And the state of the 'parser' may be
> used to select a response strategy in an AI. I wanted it for a game I
> was going to write a few years back which would construct strategies
> from various elements by building them into a kind of grammar, and use
> the resulting state model as a real time AI.
> 
>>Perhaps this is 
>>the cause of our different world views (on this issue).  Just a 
>>thought,  though it is interesting we both chose Python.
> 
> Strictly speaking, the reason I chose Python at the time was because
> at work we used macs with terminal emulators. If you wanted a utility,
> you either wrote it under VMS or you were stuffed as mac interpreters
> and compilers were hard to come by.
> 
> I see it as one of the happiest flukes - I just wish I'd found Python
> earlier.

Interesting.  I chose it mainly because I was experimenting with 
Smalltalk to learn dynamic programming, and it seemed a more practical 
language (I never got used to the whole image thing in Smalltalk).  One 
of the things that I really liked about both languages is how they 
handled references.  Perhaps that's why I'm so vehement about this whole 
topic.  Well, that and too much caffeine.

Adam Ruth