anything like C++ references?
owski at hotmail.com
Wed Jul 16 22:27:23 CEST 2003
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
>> > 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
def __getitem__(self, name):
if name in self.cache:
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.
More information about the Python-list