anything like C++ references?

[Adam Ruth]

In <donn-F604B9.12121916072003 at nntp3.u.washington.edu> Donn Cave  wrote:
> In article <20030716123907246-0600 at news.xmission.com>,
>  Adam Ruth <owski at hotmail.com> wrote:
>> In <donn-6E63A0.10284316072003 at nntp1.u.washington.edu> Donn Cave  
>> wrote:
>> > In article <20030716081156943-0600 at news.xmission.com>,
>> >  Adam Ruth <owski at hotmail.com> wrote:
>> > 
>> >> In <1058328099.572993 at yasure> Donn Cave wrote:
>> >> > Quoth Adam Ruth <owski at hotmail.com>:
>> >> > ....
>> >> >| In Python, there is no situation where "you really can't avoid 
>> >> >| pointers".  
>> >> > 
>> >> > That's trivially true, no such situation can exist because that
>> >> > Python can't be coded.  I'll repeat an example that I proposed
>> >> > a couple days ago, though:  user implemented sequences could be
>> >> > implemented with a single simple indexing function, returning
>> >> > a pointer/target/whatever;  Python could assign directly to that,
>> >> > making "seq[i] = x" the same kind of operation as and 
>> >> > automatically symmetrical with "x = seq[i]".
>  
> ....
>> You are correct, 'really need' is not much of an argument.  The 
>> statement I disagreed with was that it was bad to simulate pointers 
>> in  those situations where "you really can't avoid pointers".  I was 
>> expressing that really aren't any such situations, and that it's even 
>> worse try to simulate pointers when it's not really necessary.
> 
> OK, there really aren't any situations where you can't avoid
> pointers ... so you're ready with a solution to the problem
> I posed above?
> 
> Class scope containers that hold exactly one item, to pick a
> commonly seen usage that I suppose is a simulated pointer -
> that's really not necessary, and it's "even worse" (than what?)
> 
>    Donn Cave, donn at u.washington.edu

"Even worse" doesn't make much sense, there, does it?  I meant, faking 
pointers isn't bad because a pointer would be better, but faking 
pointers is bad because you don't need a pointer.  That makes more sense.

As for your problem on the subscript operator, I think my solution is: 
there's no problem.  Having the get and set asymetric is preferrable, in 
my view.  For example, I use it in a number of places where I cache the 
set operation:

def __getitem__(self, name):
	if name in self.cache:
		return self.cache[name]
	else:
		return someLongOperation(name)

def __setitem__(self, name, value):
	self.cache[name] = value

There are other reasons to have them as separate operations, but this is 
one that I have in a project I'm on now.  I think of them as logically 
separate operations, not necessarily opposite sides of the same coin.

Adam Ruth