Addressing the last element of a list

[pinkfloydhomer]

Isn't there an easier way than

lst[len(lst) - 1] = ...

?

[pinkfloydhomer]

Or alternatively:

Is there a way to make reference to the last element of a list, to use
as a shorthand:

ref := &lst[len(lst) - 1] # I know syntax is wrong, but you get the
idea

and then using the last element of the list by (assuming the element is
a dict):

ref["foo"] = 42
ref["bar"] = "Ni!"

etc.

/David

[Andreas Lobinger]

Aloha,

pi************@gmail.com wrote:

Isn't there an easier way than
lst[len(lst) - 1] = ...

lst[-1] = ...

Wishing a happy day
LOBI

[pinkfloydhomer]

I knew there was an easy way :)

Just to satisfy my curiousity: Is there a way to do something like the
reference solution I suggest above?

[Peter Otten]

pi************@gmail.com wrote:

Just to satisfy my curiousity: Is there a way to do something like the
reference solution I suggest above?

No. You cannot overload assignment.
Of course, for mutable objects you can use the object as the "reference" to
itself.

Peter

[Jerzy Karczmarczuk]

Peter Otten wrote:

pi************@gmail.com wrote:

Just to satisfy my curiousity: Is there a way to do something like the
reference solution I suggest above?

No. You cannot overload assignment.

I have the impression that this is not an issue, to overload assignments,
which btw. *can* be overloaded, but the absence of *aliasing* (undiscriminate
handling of pointers) in Python. Am I wrong?

Jerzy Karczmarczuk

[pinkfloydhomer]

So there is no way in Python to make an alias for an object?

/David

[bonono]

what do you mean by alias ?

a = b

now both a and b refers to the same object.

pi************@gmail.com wrote:

So there is no way in Python to make an alias for an object?

/David

[pinkfloydhomer]

I just want an alias. Ideally, I don't want to deal with pointers or
special reference "types" etc. After all, this is not C++ :)

I just want to be able to make a reference to any old thing in Python.
A list, an integer variable, a function etc. so that I, in complicated
cases, can make a shorthand. If "myRef" could somehow "point at"
something long an complicated like a[42]["pos"][-4], that might be
useful.

/David

[pinkfloydhomer]

But if lst[42]["pos"] happens to hold an integer value, then

a = lst[42]["pos"]

will _copy_ that integer value into 'a', right? Changing 'a' will not
change the value at lst[42]["pos"]

[Bengt Richter]

On 8 Nov 2005 01:12:07 -0800, "pi************@gmail.com" <pi************@gmail.com> wrote:

I knew there was an easy way :)

Just to satisfy my curiousity: Is there a way to do something like the
reference solution I suggest above?

If the last element in the list was a dict, then you could do something like

lst = ['the', 'last', 'element of this list is a dict', {'key':"key's value"}]
ref = lst[-1]
ref {'key': "key's value"} ref["foo"] =42
ref['bar'] = 'Ni!'
ref {'foo': 42, 'bar': 'Ni!', 'key': "key's value"} ref['key'] "key's value" ref['bar'] 'Ni!' del ref['key']
ref

{'foo': 42, 'bar': 'Ni!'}

FWIW ;-)

Regards,
Bengt Richter

[Simon Brunning]

On 8 Nov 2005 01:43:43 -0800, pi************@gmail.com
<pi************@gmail.com> wrote:

But if lst[42]["pos"] happens to hold an integer value, then

a = lst[42]["pos"]

will _copy_ that integer value into 'a', right?
Nope. It will bind the name 'a' to the integer object.
Changing 'a' will not
change the value at lst[42]["pos"]

Integers are immutable - they can't be modified. So, "Changing 'a'"
means binding the name 'a' to a different object. This will have no
effect on other references to the original object.

Reset your brain - <http://effbot.org/zone/python-objects.htm>.

--
Cheers,
Simon B,
si***@brunningonline.net,
http://www.brunningonline.net/simon/blog/

[Bengt Richter]

On 8 Nov 2005 01:43:43 -0800, "pi************@gmail.com" <pi************@gmail.com> wrote:

But if lst[42]["pos"] happens to hold an integer value, then

a = lst[42]["pos"]

will _copy_ that integer value into 'a', right? Changing 'a' will not
change the value at lst[42]["pos"]

Right, but try an example:

lst = range(42)+[{'pos':123}]+range(43,50)
lst [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 2
6, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, {'pos': 123}, 43, 44, 45, 46, 47,
48, 49] lst[41:44] [41, {'pos': 123}, 43] lst[42] {'pos': 123} lst[42]['pos'] 123 a = lst[42]['pos']
a 123 lst[42]['pos'] 123 id(lst[42]['pos']) 49421860 id(a)

49421860

IOW, a is now an alias for the same 123 immutable integer object as is referred to by the 'pos' key
in the dict which is the 43rd element (index 42) of lst.

Regards,
Bengt Richter

[Peter Otten]

Jerzy Karczmarczuk wrote:

Peter Otten wrote:

pi************@gmail.com wrote:

Just to satisfy my curiousity: Is there a way to do something like the
reference solution I suggest above?

No. You cannot overload assignment.

I have the impression that this is not an issue, to overload assignments,
which btw. *can* be overloaded, but the absence of *aliasing*
(undiscriminate handling of pointers) in Python. Am I wrong?

I think so.

a = b

will always make a a reference to (the same object as) b. What can be
overloaded is attribute assignment:

x.a = b

can do anything from creating an attribute that references b to wiping your
hard disk.

I don't understand what you mean by "absence of aliasing", but conceptually
every python variable is a -- well-behaved -- pointer.

Peter

[bonono]

If you want to do what you want(though I don't know why without a
concrete example), just store a mutable object at lst[42]["pos"], like
this :

lst[42]["pos"] = [1]

a = lst[42]["pos"]
a[0] = 2
assert(lst[42]["pos"][0] == 2)

pi************@gmail.com wrote:

But if lst[42]["pos"] happens to hold an integer value, then

a = lst[42]["pos"]

will _copy_ that integer value into 'a', right? Changing 'a' will not
change the value at lst[42]["pos"]

[Peter Otten]

pi************@gmail.com wrote:

I just want an alias. Ideally, I don't want to deal with pointers or
special reference "types" etc. After all, this is not C++ :)

I just want to be able to make a reference to any old thing in Python.
A list, an integer variable, a function etc. so that I, in complicated
cases, can make a shorthand. If "myRef" could somehow "point at"
something long an complicated like a[42]["pos"][-4], that might be
useful.

You can do

shorthand = a[42]["pos"]

....

print shorthand[-4]
shorthand[0] = 42 # if a[42]["pos"] is mutable

But the last indirection must always be given explicitly.

Peter

[Jerzy Karczmarczuk]

Peter Otten wrote cites me:

I have the impression that this is not an issue, to overload assignments,
which btw. *can* be overloaded, but the absence of *aliasing*
(undiscriminate handling of pointers) in Python. Am I wrong?

I think so.

a = b

will always make a a reference to (the same object as) b. What can be
overloaded is attribute assignment:

x.a = b

can do anything from creating an attribute that references b to wiping your
hard disk.

I don't understand what you mean by "absence of aliasing", but conceptually
every python variable is a -- well-behaved -- pointer.

Would you please concentrate on - what I underlined - the sense of "C" aliasing,
where you can make a pointer to point to anything, say, the 176th byte of a
function code?

*This* is impossible in Python. What you wrote is OK, but I still don't know
where I have been wrong, unless you over-interpret my words. Sure, I didn't
want to claim that the assignment a=anything can be plainly overloaded. But
getitem, setitem, getattr, setattr - yes. And they (set-) are also assignments.

Jerzy Karczmarczuk

[Peter Otten]

Jerzy Karczmarczuk wrote:

Sure, I didn't want to claim that the assignment a=anything can be plainly
overloaded.
I interpreted your previous post as such a claim. No disagreement here then.
Would you please concentrate on - what I underlined - the sense of "C"
aliasing, where you can make a pointer to point to anything, say, the
176th byte of a function code?
I've never heard the expression "aliasing" for that, sorry.
This is impossible in Python.

Of course, but I don't think this is what the OP wanted.

Peter

[Matt Hammond]

On Tue, 08 Nov 2005 10:25:21 -0000, Jerzy Karczmarczuk
<ka*****@info.unicaen.fr> wrote:

Would you please concentrate on - what I underlined - the sense of "C"
aliasing,
where you can make a pointer to point to anything, say, the 176th byte
of a
function code?

Pretty much everything is referred to by reference in python. The big
difference is that most
primitive data types (integer, string) etc... aren't mutable - you can't
change them in place - instead you replace them with a new instance
containing the new/modified value.

But your own object and lists are mutable - you can change their
attributes. So encapsulate data within a list or as an attribute of an
object and you've got the effect you're after.

For example:

a = 5; b = a
a = 6
a,b (6, 5)

Whereas:
a = [5]; b = a
a[0] = 6
a,b ([6], [6])

Note that reassigning a: a = [6]

causes a to point to a new list, containing the value 6, whereas the 2nd
example above modified the list by replacing an element of it.
Hope this helps
Matt

--

| Matt Hammond
| R&D Engineer, BBC Research & Development, Tadworth, Surrey, UK.
| http://kamaelia.sf.net/
| http://www.bbc.co.uk/rd/

[Giovanni Bajo]

pi************@gmail.com wrote:

I just want an alias.
What you want is impossible. But there are many workarounds.
I just want to be able to make a reference to any old thing in Python.
A list, an integer variable, a function etc. so that I, in complicated
cases, can make a shorthand. If "myRef" could somehow "point at"
something long an complicated like a[42]["pos"][-4], that might be
useful.

One simple workaround:

def createAlias(L, idx1, idx2, idx3):
def setval(n):
L[idx1][idx2][idx3] = n
return setval

k = createAlias(a, 42, "pos", -4)

[...]

n = computeValue(...)
k(n) # store it!
You will also find out that your case is actually very unlikely in
well-designed code. You don't usually work with stuff with three level of
nesting like a[][][], since it gets totally confusing and unmaintanable. You
will end up always with objects with better semantic, and methods to modify
them. So in the end you will always have a reference to the moral equivalent of
a[42]["pos"], and that would be a well defined object with a method setThis()
which will modify the moral equivalent of [-4].
--
Giovanni Bajo

[Steven D'Aprano]

On Tue, 08 Nov 2005 01:31:31 -0800, pi************@gmail.com wrote:

So there is no way in Python to make an alias for an object?

Yes, sort of. Bind two names to the same mutable object:

py> x = ["Something mutable"]
py> y = x
py> y.append("this way comes.")
py> print x
['Something mutable', 'this way comes.']

Note that this only works with mutable objects like lists and dicts, and
is a side effect of mutability, rather than a deliberate "alias".

In general, you can bind multiple names to the same object. The one liner

x = y = 1

is the same as the two liner

x = 1
y = x

Both create two names, x and y, and sets them both to the same int 1.

Because ints are immutable, if you rebind one name, the other one will
NOT change:

py> x += 1
py> print x, y
2, 1
--
Steven.

[Steven D'Aprano]

On Tue, 08 Nov 2005 01:04:13 -0800, pi************@gmail.com wrote:

Or alternatively:

Is there a way to make reference to the last element of a list, to use
as a shorthand:

ref := &lst[len(lst) - 1] # I know syntax is wrong, but you get the
idea

and then using the last element of the list by (assuming the element is
a dict):

ref["foo"] = 42
ref["bar"] = "Ni!"

py> lst = ["Now is the time", 4, "all good men", {"foo": "bar"}]
py> lst[-1] # refers to the last item of lst
{'foo': 'bar'}
py> obj = lst[-1] # the name obj is now bound to the same dict
py> obj["foo"] = 42
py> print lst
['Now is the time', 4, 'all good men', {'foo': 42}]

This only works with mutable objects. See:

py> obj = lst[-3]
py> obj
4
py> obj = obj + 1 # rebinds the name obj, doesn't change the underlying
object the name points to
py> print lst
['Now is the time', 4, 'all good men', {'foo': 42}]

You will quickly learn what are mutable and what are immutable. Ints,
floats, longs, strs and tuples are immutable. Lists and dicts are mutable.
Custom classes could be either, in principle, but are generally mutable.

--
Steven.

[Steven D'Aprano]

On Tue, 08 Nov 2005 01:43:43 -0800, pi************@gmail.com wrote:

But if lst[42]["pos"] happens to hold an integer value, then

a = lst[42]["pos"]

will _copy_ that integer value into 'a', right? Changing 'a' will not
change the value at lst[42]["pos"]

Not quite. Don't think of Python names as being like variables.

Think of it like this: in Python, everything is an object. You reference
objects by creating a name, and binding that name to an object:

py> parrot = {'feathers': 'beautiful plumage'}

This creates a name, parrot, and binds it to the dictionary given.

If the underlying object is mutable, like dicts and lists, you can modify
the object in place:

py> parrot['state'] = 'pining for the fjords'
py> parrot['breed'] = 'Norwegian Blue'
py> print parrot
{'feathers': 'beautiful plumage', 'state': 'pining for the fjords',
'breed': 'Norwegian Blue'}

But immutable objects can't be changed in place (that's what immutable
means). Ints are immutable objects, so you can't change the value of the
int object 1: 1 is always 1.

(Imagine the confusion if you changed the object 1 to have a value of 3;
you could say 1 + 2 and get 5. That would be a *really* bad idea.)

So when working with ints, strs or other immutable objects, you aren't
modifying the objects in place, you are rebinding the name to another
object:

py> spam = "a tasty meat-like food"
py> alias = spam # both names point to the same str object
py> spam = "spam spam spam spam" # rebinds name to new str object
py> print spam, alias
'spam spam spam spam' 'a tasty meat-like food'
--
Steven.

[Dennis Lee Bieber]

On 8 Nov 2005 01:43:43 -0800, "pi************@gmail.com"
<pi************@gmail.com> declaimed the following in comp.lang.python:

But if lst[42]["pos"] happens to hold an integer value, then
lst[42]["pos"]

is ALREADY a reference to an integer value
a = lst[42]["pos"]
a

is NOW a reference to the same integer value
will _copy_ that integer value into 'a', right? Changing 'a' will not
change the value at lst[42]["pos"]
No... "a" now references the same integer... But in Python you can
NOT change an integer. So an subsequent assignment to "a"

a = xyz

doesn't change the integer, it changes "a" to NOW references whatever
object "xyz" references.
Time for the Post-It note simile.

Classical languages use the "post office sorting box" view. Each box
(variable name) has a fixed address, that can not be changed.

a = xyz

means "look in the box 'xyz', make a copy of what is in there, and put
that copy in the box 'a' (removing anything that had been in box 'a')"

In Python, the boxes (variable names) don't have fixed addresses.
Instead, the names are "on Post-It notes".

a = xyz

means "find the Post-It with 'a' written on it; if not found, create a
new Post-It. MOVE that Post-It from where ever you found it, to the box
that has a Post-It with 'xyz' written on it. If the location you'd found
'a' has NO Post-It notes on it, garbage collect it"

Note that: the object (integer, whatever) is NOT attached to the
name, rather the name is attached to the object -- one object can have
many names (after the above example, the object has two names minimum
"a" and "xyz" are both stuck to the object). If you now do an assignment
to one of the names, /that/ name gets /moved/ to the new object.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

[Michael]

pi************@gmail.com wrote:

Is there a way to make reference to the last element of a list, to use
as a shorthand:

Yes. It's not wise to use, since this is brittle and will fail hard for you,
but since you're interested, this is how you /could/ do it: (largely)

# First of all create a mechanism for creating and handling symbolic
# references
class ref(object):
def __init__(self, val):
self._val = val
def set_val(self, val):
exec("global %s\n%s = %s" % (self._val, self._val, repr(val)))
def get_val(self):
return eval(self._val)
val = property(get_val, set_val)

Now we can play with this.

Note the word *PLAY* .

lst = ["1","2","3","4"]
y = ref("lst[-1]")
y.val '4' y.val = 10
y.val 10 lst ['1', '2', '3', 10] i = 1
z = ref("i")
z.val = 10
i

10

Once again, note the word *play* - don't use this in __anything__ :-)
Python binds values to names. As a result what you're after when asking
for

ref := &lst[len(lst) - 1]

And then for ref to actually refer to that last item, you have to realise
that you're asking for an indirection on the name "lst[-1]". Short of doing
silly things with eval and exec (which you really don't want to do), you
can't do this.

However, it's python, so of course you *can*, but just because you *can* do
something doesn't mean that you *should*.

You'll note that in order to make the reference to the plain mutable
value (i) work the set_val had to mark the value as global, which isn't
quite right. (You might be able to trick it into using the "right" scope
using lambda somehow, maybe)

Once again, don't use it! (hopefully of interest though)

Regards,
Michael.
--
http://kamaelia.sourceforge.net/

[Donn Cave]

Quoth Steven D'Aprano <st***@REMOVETHIScyber.com.au>:
....
| So when working with ints, strs or other immutable objects, you aren't
| modifying the objects in place, you are rebinding the name to another
| object:
|
| py> spam = "a tasty meat-like food"
| py> alias = spam # both names point to the same str object
| py> spam = "spam spam spam spam" # rebinds name to new str object
| py> print spam, alias
| 'spam spam spam spam' 'a tasty meat-like food'

The semantics of assignment are like that, period. If the right hand
side is an int, a string, a class instance, a list, whatever, doesn't
matter at all. The question of mutability at this point can be a red
herring for someone who doesn't already understand these matters.

Mutability is nothing special, it's just a feature built into the
object type -- in general, the ability to store some state. This
is of course useful in situations where we want to propagate state
changes, so it naturally comes up in this context, but language per
se does not observe any distinction here so far as I know.

Donn Cave, donn@drizzle.

[Steven D'Aprano]

On Thu, 10 Nov 2005 06:47:41 +0000, Donn Cave wrote:

Quoth Steven D'Aprano <st***@REMOVETHIScyber.com.au>:
...
| So when working with ints, strs or other immutable objects, you aren't
| modifying the objects in place, you are rebinding the name to another
| object:
|
| py> spam = "a tasty meat-like food"
| py> alias = spam # both names point to the same str object
| py> spam = "spam spam spam spam" # rebinds name to new str object
| py> print spam, alias
| 'spam spam spam spam' 'a tasty meat-like food'

The semantics of assignment are like that, period. If the right hand
side is an int, a string, a class instance, a list, whatever, doesn't
matter at all. The question of mutability at this point can be a red
herring for someone who doesn't already understand these matters.

Yes, but in the context we were discussing, the original poster was
specifically asking to do something that is only possible with mutable
objects.

He wanted to do something like this:

data = [0, None, 2, ["hello"]]
ref = data[-1]
ref.append("world")

and end up with [0, None, 2, ["hello", "world"]]. That will work, because
the last item in data is mutable. But this will NOT work:

data = [0, None, 2, 0]
ref = data[-1]
ref = 1
assert data[-1] == 1

because ints are immutable. So the distinction between modifying a
mutable object in place and assigning is important.

--
Steven.

[Antoon Pardon]

Op 2005-11-10, Steven D'Aprano schreef <st***@REMOVETHIScyber.com.au>:

On Thu, 10 Nov 2005 06:47:41 +0000, Donn Cave wrote:

Quoth Steven D'Aprano <st***@REMOVETHIScyber.com.au>:
...
| So when working with ints, strs or other immutable objects, you aren't
| modifying the objects in place, you are rebinding the name to another
| object:
|
| py> spam = "a tasty meat-like food"
| py> alias = spam # both names point to the same str object
| py> spam = "spam spam spam spam" # rebinds name to new str object
| py> print spam, alias
| 'spam spam spam spam' 'a tasty meat-like food'

The semantics of assignment are like that, period. If the right hand
side is an int, a string, a class instance, a list, whatever, doesn't
matter at all. The question of mutability at this point can be a red
herring for someone who doesn't already understand these matters.

Yes, but in the context we were discussing, the original poster was
specifically asking to do something that is only possible with mutable
objects.

He wanted to do something like this:

data = [0, None, 2, ["hello"]]
ref = data[-1]
ref.append("world")

and end up with [0, None, 2, ["hello", "world"]]. That will work, because
the last item in data is mutable. But this will NOT work:

data = [0, None, 2, 0]
ref = data[-1]
ref = 1
assert data[-1] == 1

because ints are immutable. So the distinction between modifying a
mutable object in place and assigning is important.

I wonder couldn't this be done with properties?

Write somekind of property so that if you manipulate a.x it would
manipulate data[-1]

--
Antoon Pardon

[Peter Otten]

Antoon Pardon wrote:

Write somekind of property so that if you manipulate a.x it would
manipulate data[-1]

Like that?

def make_prp(index): .... def get(self): return self[index]
.... def set(self, value): self[index] = value
.... return property(get, set)
.... class List(list): .... first = make_prp(0)
.... last = make_prp(-1)
.... items = List([1,2,3])
items.first 1 items.last = 42
items

[1, 2, 42]

However, that's customizing attribute access, not name binding.

Peter

[Daniel Crespo]

Hi

Proposition 1:

data = [0, None, 2, 0]
ref = data[-1]
ref = 1
assert data[-1] == 1

Logically, it doesn't work. Here you are assigning to ref a NEW value.
That won't replace the data[-1] value. It's out of logic this
proposition.

While this (proposition 2):
data = [0, None, 2, ["hello"]]
ref = data[-1]
ref.append("world")

does work, because you are assigning to ref THAT list ["hello"]. So, if
you have THAT list, and appends a value, THAT list will be modified.
ref is pointing to THAT object. So, I don't understand why you write
the first proposition, like if that can be a normal thinking of how to
do the second proposition :-S

Well, I hope that newcomers to Python don't confuse himselves :)

Daniel

[bonono]

This mutable/immutable object and name/variable is confusing.

Daniel Crespo wrote:

Well, I hope that newcomers to Python don't confuse himselves :)

Daniel

[Mike Meyer]

[Context recovered from top posting.]

"bo****@gmail.com" <bo****@gmail.com> writes:

Daniel Crespo wrote:

Well, I hope that newcomers to Python don't confuse himselves :)

This mutable/immutable object and name/variable is confusing.

Only if you have to overcome a conviction that variables behave in a
different way. If you've never seen them behave another way, or have
already gotten used to this model from another language (it dates back
to the 60s, if not the late 50s), then it's no problem. I'm sure the
problem exists in the opposite direction, except that few people
travel that route.

Most OO languages do the name/variable thing, but some of the popular
ones aren't consistent about it, giving some types "special" status,
so that sometimes "a = b" causes b to be copied onto a, and sometimes
it causes a to become a pointer to b. I find a consistent approach is
preferable.

Most OO languages also have the mutable/immutable object thing. The
set of which objects are immutable changes from language to
language. It's really only relevant in this case because the solution
to "I want to change an alias" issue involves using a mutable object.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[bonono]

After one knows the characteristic, it is no problem. But judging from
the frequency of the same issue coming up from time to time, it does
confuse people coming from certain programming background.

Mike Meyer wrote:

Only if you have to overcome a conviction that variables behave in a
different way. If you've never seen them behave another way, or have
already gotten used to this model from another language (it dates back
to the 60s, if not the late 50s), then it's no problem. I'm sure the
problem exists in the opposite direction, except that few people
travel that route.

Most OO languages do the name/variable thing, but some of the popular
ones aren't consistent about it, giving some types "special" status,
so that sometimes "a = b" causes b to be copied onto a, and sometimes
it causes a to become a pointer to b. I find a consistent approach is
preferable.

Most OO languages also have the mutable/immutable object thing. The
set of which objects are immutable changes from language to
language. It's really only relevant in this case because the solution
to "I want to change an alias" issue involves using a mutable object.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Donn Cave]

In article <86************@bhuda.mired.org>, Mike Meyer <mw*@mired.org>
wrote:
....

Most OO languages do the name/variable thing, but some of the popular
ones aren't consistent about it, giving some types "special" status,
so that sometimes "a = b" causes b to be copied onto a, and sometimes
it causes a to become a pointer to b. I find a consistent approach is
preferable.
Who wouldn't.
Most OO languages also have the mutable/immutable object thing. The
set of which objects are immutable changes from language to
language. It's really only relevant in this case because the solution
to "I want to change an alias" issue involves using a mutable object.

Yes, and furthermore it's only vaguely relevant. I mean,
it really requires a particular kind of mutability, where one
object can store a reference to another. That's easy to find
in core object types, and of course it is a kind of mutability,
but it isn't the definition of mutable.

So we drag out this terminology, that neither clearly nor
accurately describes the functionality we have in mind,
and then we make some vague or even wrong statement about
its relationship to the issue. It has been going on for
years, usually I believe from people who understand quite
well how it really works.

Donn Cave, do**@u.washington.edu

[Steven D'Aprano]

On Thu, 10 Nov 2005 08:19:36 -0800, bo****@gmail.com wrote:

This mutable/immutable object and name/variable is confusing.

It is a source of confusion to newbies, because it is a distinction that
may not be intuitively obvious, and it is a programming model that isn't
quite the same as many people are used to.

One way that may help thinking about it is to imagine that Python names
are "like" pointers. That may make people feel less threatened, since
pointers in languages that use them often confuse beginners too.

As for mutable/immutable, that's simple too. Some objects can change their
value, and some objects can't.

But the best way to get an intuitive feel for how Python operates is to
start up an interactive session and just experiment!
--
Steven.

[Antoon Pardon]

Op 2005-11-10, Mike Meyer schreef <mw*@mired.org>:

[Context recovered from top posting.]

"bo****@gmail.com" <bo****@gmail.com> writes:

Daniel Crespo wrote:

Well, I hope that newcomers to Python don't confuse himselves :)

This mutable/immutable object and name/variable is confusing.

Only if you have to overcome a conviction that variables behave in a
different way. If you've never seen them behave another way, or have
already gotten used to this model from another language (it dates back
to the 60s, if not the late 50s), then it's no problem. I'm sure the
problem exists in the opposite direction, except that few people
travel that route.

Most OO languages do the name/variable thing, but some of the popular
ones aren't consistent about it, giving some types "special" status,
so that sometimes "a = b" causes b to be copied onto a, and sometimes
it causes a to become a pointer to b. I find a consistent approach is
preferable.

But what about a consistent approach, that allows choice.

Like having an assignment operator (let use @= for it) next to a
(re)bind operator.

We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

I think such option is usefull and I sometimes miss it in python.

--
Antoon Pardon

[Paul Rubin]

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

Ouch! :-(((

Can't you live with

a = [5]
b = a
a[0] = 7

so b[0] is now 7.

[Antoon Pardon]

Op 2005-11-14, Paul Rubin schreef <http>:

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

Ouch! :-(((

Can't you live with

a = [5]
b = a
a[0] = 7

so b[0] is now 7.

And what do I have to do, in case of the following:

a = [3, 5]
b = a[0]
b @= 7
a ==> would result in [7, 5]

This may seem contrived, but in combination with
parameters it could be usefull.

Something like:

a = [3, 5]

def treat(b):
lots of code
b @= new_value

f(a[0])
a ==> would result in [7, 5]

--
Antoon Pardon

[Mike Meyer]

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Op 2005-11-10, Mike Meyer schreef <mw*@mired.org>:

[Context recovered from top posting.]
"bo****@gmail.com" <bo****@gmail.com> writes:

Daniel Crespo wrote:
Well, I hope that newcomers to Python don't confuse himselves :)
This mutable/immutable object and name/variable is confusing. Only if you have to overcome a conviction that variables behave in a
different way. If you've never seen them behave another way, or have
already gotten used to this model from another language (it dates back
to the 60s, if not the late 50s), then it's no problem. I'm sure the
problem exists in the opposite direction, except that few people
travel that route.
Most OO languages do the name/variable thing, but some of the popular
ones aren't consistent about it, giving some types "special" status,
so that sometimes "a = b" causes b to be copied onto a, and sometimes
it causes a to become a pointer to b. I find a consistent approach is
preferable.

But what about a consistent approach, that allows choice.

It's been done in other languages. But it requires more care than one
would think.
Like having an assignment operator (let use @= for it) next to a
(re)bind operator.

We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

You've just overwritten the object referred to by the token "5" in the
source code with the value 7, so you get:

print 5
7

Not exactly a desirable outcome, but some language implementations
have allowed this kind of thing in the past. You either have to make
all objects mutable, or disallow assignment to immutable objects,
which sort of defeats the purpose.

Another approach is to have a special object type if you want to allow
assignment to the object it refers to. That's what Python does now, it
just doesn't have a syntax just to support that. If it did, your
example might look like:

a := 5
b = @a
a := 7
@b ==> would result in 7

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Bengt Richter]

On 14 Nov 2005 11:20:53 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2005-11-14, Paul Rubin schreef <http>:

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

Ouch! :-(((

Can't you live with

a = [5]
b = a
a[0] = 7

so b[0] is now 7.

And what do I have to do, in case of the following:

a = [3, 5]
b = a[0]
b @= 7
a ==> would result in [7, 5]

This may seem contrived, but in combination with
parameters it could be usefull.

Something like:

a = [3, 5]

def treat(b):
lots of code
b @= new_value

f(a[0])
a ==> would result in [7, 5]

--

You may be interested in reviewing

http://groups.google.com/group/comp....d3539e928986b3

before continuing this topic ;-)

Regards,
Bengt Richter

[bonono]

Bengt Richter wrote:

You may be interested in reviewing

http://groups.google.com/group/comp....d3539e928986b3

before continuing this topic ;-)

Interesting indeed, I mean the argument of why python does it this way.

I see the equivalent of telling someone who's language read right to
left about English :

"What ? you don't know all good language should be read left to right".

[Bengt Richter]

On Mon, 14 Nov 2005 09:53:34 -0500, Mike Meyer <mw*@mired.org> wrote:

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Op 2005-11-10, Mike Meyer schreef <mw*@mired.org>:

[Context recovered from top posting.]
"bo****@gmail.com" <bo****@gmail.com> writes:
Daniel Crespo wrote:
> Well, I hope that newcomers to Python don't confuse himselves :)
This mutable/immutable object and name/variable is confusing.
Only if you have to overcome a conviction that variables behave in a
different way. If you've never seen them behave another way, or have
already gotten used to this model from another language (it dates back
to the 60s, if not the late 50s), then it's no problem. I'm sure the
problem exists in the opposite direction, except that few people
travel that route.
Most OO languages do the name/variable thing, but some of the popular
ones aren't consistent about it, giving some types "special" status,
so that sometimes "a = b" causes b to be copied onto a, and sometimes
it causes a to become a pointer to b. I find a consistent approach is
preferable.

But what about a consistent approach, that allows choice.

It's been done in other languages. But it requires more care than one
would think.

Like having an assignment operator (let use @= for it) next to a
(re)bind operator.

We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

You've just overwritten the object referred to by the token "5" in the
source code with the value 7, so you get:

print 5
7

Not exactly a desirable outcome, but some language implementations
have allowed this kind of thing in the past. You either have to make
all objects mutable, or disallow assignment to immutable objects,
which sort of defeats the purpose.

Another approach is to have a special object type if you want to allow
assignment to the object it refers to. That's what Python does now, it
just doesn't have a syntax just to support that. If it did, your
example might look like:

a := 5
b = @a
a := 7
@b ==> would result in 7

If you are willing to keep your "variables" in a namespace, it's easy
to make "pointers" that you can dereference like @b, except
-- given a preliminary:
(see PNS from http://groups.google.com/group/comp....a7ab01906683ca )

from pns import PNS
class NS(object): ... def __call__(self, name): return PNS(self, name)
... ns = NS()
-- and then you have to spell it a little differently:
ns.a = 5 # a := 5
b = ns('a') # b = @a
ns.a = 7 # a := 7
b.v # @b 7
For another slant, laundering all ns assignments through pickle dumps/loads
to get a fresh value so as not to share references, and simulate value
assignment sematics (I think? ;-/)

http://groups.google.com/group/comp....9cf8e25b42d5cb

with a different spelling for pointer use (ns['a'] instead of ns('a') above,
and b[:] instead of b.v)

The class also gave you a way to spell the typical C address/pointer/deref ops.
It's based on a name space class that gives you a name space object (say ns)
for the "variables" that you can get "pointers" to like ptr = &var and which
you can pass around and use with dereferencing like *ptr for either assignment
or on the right hand side. Once you have a names space ns = NSHorne() you can
set variables in the ordinary way as attributes, or get "pointers" and use
them via *p semantics
from ns_horne import NSHorne
ns = NSHorne()
ns.x = 'x value'
ptr = ns['x']
ptr[:] 'x value'

Now make a function that will use the pointer def set(p, v): ... p[:] = v
... set(ptr, 123)
Check indirect result ns.x 123 ptr[:] 123 ptr[:] += 321
ns.x 444

Pseudo-value-semantics: from ns_horne import NSHorne
ns = NSHorne()
ns.z = [1,2]
pz = ns['z']
pz[:] [1, 2] ns.z2 = pz[:]
ns.z [1, 2] ns.z2 [1, 2] pz[:][0]='z via pz'
ns.z ['z via pz', 2] ns.z2 [1, 2] pz[:] ['z via pz', 2]

Or value semantics without confusing with pointer stuff: ns.z3 = ns.z2
now equal values, but not the same objects: ns.z3, ns.z2 ([1, 2], [1, 2]) ns.z2[1]='z2 via ns.z2'
ns.z3 [1, 2] ns.z2

[1, 'z2 via ns.z2']

Regards,
Bengt Richter

[Antoon Pardon]

Op 2005-11-14, Mike Meyer schreef <mw*@mired.org>:

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Op 2005-11-10, Mike Meyer schreef <mw*@mired.org>:

[Context recovered from top posting.]
"bo****@gmail.com" <bo****@gmail.com> writes:
Daniel Crespo wrote:
> Well, I hope that newcomers to Python don't confuse himselves :)
This mutable/immutable object and name/variable is confusing.
Only if you have to overcome a conviction that variables behave in a
different way. If you've never seen them behave another way, or have
already gotten used to this model from another language (it dates back
to the 60s, if not the late 50s), then it's no problem. I'm sure the
problem exists in the opposite direction, except that few people
travel that route.
Most OO languages do the name/variable thing, but some of the popular
ones aren't consistent about it, giving some types "special" status,
so that sometimes "a = b" causes b to be copied onto a, and sometimes
it causes a to become a pointer to b. I find a consistent approach is
preferable. But what about a consistent approach, that allows choice.

It's been done in other languages. But it requires more care than one
would think.

That is possible.

Like having an assignment operator (let use @= for it) next to a
(re)bind operator.

We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

You've just overwritten the object referred to by the token "5" in the
source code with the value 7, so you get:

print 5
7

Not exactly a desirable outcome, but some language implementations
have allowed this kind of thing in the past. You either have to make
all objects mutable, or disallow assignment to immutable objects,
which sort of defeats the purpose.

You have a valid point, but I think a different approach is possible.
Don't make the distinction between mutable and immutable types but
between mutable and immutable objects. So an int wouldn't be an
immutable type, but 5 would be an immutable object.

So the code above I gave would throw an exception, but the following
might work.

a @= 5
b = a
b @= 7
a ==> would result in 7.
Another approach is to have a special object type if you want to allow
assignment to the object it refers to. That's what Python does now, it
just doesn't have a syntax just to support that. If it did, your
example might look like:

a := 5
b = @a
a := 7
@b ==> would result in 7

Could it also work the other way? By somehow manipulating b change a?

--
Antoon Pardon

[Antoon Pardon]

Op 2005-11-14, Bengt Richter schreef <bo**@oz.net>:

On 14 Nov 2005 11:20:53 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2005-11-14, Paul Rubin schreef <http>:

Antoon Pardon <ap*****@forel.vub.ac.be> writes:
We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

Ouch! :-(((

Can't you live with

a = [5]
b = a
a[0] = 7

so b[0] is now 7.

And what do I have to do, in case of the following:

a = [3, 5]
b = a[0]
b @= 7
a ==> would result in [7, 5]

This may seem contrived, but in combination with
parameters it could be usefull.

Something like:

a = [3, 5]

def treat(b):
lots of code
b @= new_value

f(a[0])
a ==> would result in [7, 5]

--

You may be interested in reviewing

http://groups.google.com/group/comp....d3539e928986b3

before continuing this topic ;-)

It is a rather long thread. You want to avoid this one becomes of
comparable length?

--
Antoon Pardon

[Chris Mellon]

On 11/14/05, Bengt Richter <bo**@oz.net> wrote:

On 14 Nov 2005 11:20:53 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2005-11-14, Paul Rubin schreef <http>:

Antoon Pardon <ap*****@forel.vub.ac.be> writes:
We could then have something like the following.

a = 5
b = a
a @= 7
b ==> would result in 7.

Ouch! :-(((

Can't you live with

a = [5]
b = a
a[0] = 7

so b[0] is now 7.
And what do I have to do, in case of the following:

a = [3, 5]
b = a[0]
b @= 7
a ==> would result in [7, 5]

This may seem contrived, but in combination with
parameters it could be usefull.

Something like:

a = [3, 5]

def treat(b):
lots of code
b @= new_value

f(a[0])
a ==> would result in [7, 5]

--

You may be interested in reviewing

http://groups.google.com/group/comp....d3539e928986b3

before continuing this topic ;-)

I read that thread, and am glad I did before asking like I was going
to, if only to avoid being yelled at for not understanding Python
variables ;)

I understand them, I really do, and I know why they act the way they
do, but I still wanted a reference type for binding GUI objects to
data values - for example, a spinner control to an int value. In C++,
I do it by passing a pointer to an int to the control and letting it
do its thing. Theres no simple obvious way to do the same thing in
Python - I ended up by passing a namespace(any object) and an
attribute (by name) and then setting it via setattr in in the control,
which is non-obvious and icky.

Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list

[Bengt Richter]

On 15 Nov 2005 08:51:59 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2005-11-14, Bengt Richter schreef <bo**@oz.net>:

[...]

You may be interested in reviewing

http://groups.google.com/group/comp....d3539e928986b3

before continuing this topic ;-)

It is a rather long thread. You want to avoid this one becomes of
comparable length?

Not necessarily. I just thought it might help in making new discussions
of previously discussed ideas clearer faster ;-)

Sometimes rehashing old topics seems just tedious, but sometimes someone
has a hunch that they are struggling to express, and they haven't yet succeeded
in communicating its essence. Then old discussions can sometimes serve
like first drafts of a speech, and revisions can prevent repeat of misunderstandings
that in the archived discussions one can see were inevitable.

If the nascent idea comes out viable, we all benefit, and the tedium will have been
worth it. If not, well, then at least some ideas will have clearer form, and
the whole process will have been a social event that some will have enjoyed anyway ;-)

Regards,
Bengt Richter

[Bengt Richter]

On Tue, 15 Nov 2005 03:23:11 -0600, Chris Mellon <ar*****@gmail.com> wrote:

On 11/14/05, Bengt Richter <bo**@oz.net> wrote:

[...]

You may be interested in reviewing

http://groups.google.com/group/comp....hread/thread/=

f96b496b6ef14e2/32d3539e928986b3

before continuing this topic ;-)

I read that thread, and am glad I did before asking like I was going
to, if only to avoid being yelled at for not understanding Python
variables ;)

I understand them, I really do, and I know why they act the way they
do, but I still wanted a reference type for binding GUI objects to
data values - for example, a spinner control to an int value. In C++,
I do it by passing a pointer to an int to the control and letting it
do its thing. Theres no simple obvious way to do the same thing in
Python - I ended up by passing a namespace(any object) and an
attribute (by name) and then setting it via setattr in in the control,
which is non-obvious and icky.

ISTM that there are two main issues involved.
1) Can you code your intentions with some clean syntax?
1a) Is there clean syntax to help you think more fluently?
2) Is the implementation efficient enough for your use case?

(Ok, I couldn't help introducing 1a, because I think that is
where Python shines).

I think 2) can be ignored until we have a good proposal for 1) ;-)

IIUC what you want boils down to wanting to replace a value
via a reference object that you pass to a function, where the value
is known by name in some namespace, and you don't want
to use a (namespace, namestring) tuple as a reference object.

Actually, in general the value could be known by some access expression
that doesn't necessarily end in a name, like a[42]. Our magic ref expression
(let's use function syntax for now for creating the reference) becomes
more tricky. We now also have ref(a[42]) as well as ref(name).

For easy discussion of the concept, let's assume that refobj = ref(expr) works
for some subset of exprs and refobj lets us access the expr target via
refobj.value for assignment or in an expression. Note that the name 'value'
is not the name in ref(name), but is always 'value'. We can discuss later
whether we want syntactic sugar to spell refobj.value as @refobj or maybe
even plain refobj, but let's postpone that until we have agreed functionality
and some ideas on implementation.

So, to summarize, we have

refobj = ref(expr)

and we can assign to the indirect target and and use it in an expression

refobj.value = refobj.value + 1

with a fixed syntax that does not identify any of the original expression
(since "value" is an arbitrarily chosen mnemonic and attribute access is
an arbitrarily chosen accessor mechanism for discussion expediency).

For your example of ref(namespace.name) we could use my PNS class [1]
to get a refobj that acts as above, e.g.,

from pns import PNS
namespace = type('NS',(),{})() # an object providing attr namespace
refobj = PNS(namespace, 'name')
refobj.value = 'should wind up in namespace'
namespace.name 'should wind up in namespace' refobj.value 'should wind up in namespace'

[1] http://groups.google.com/group/comp....a7ab01906683ca

But how would ref(a[42]) work? By analogy we might have a class PLE (pointer
to list element) and instantiate it by refobj = PLE(a, 42). That would be easy.
One could even imagine a multimethod __init__ for a PXX class that would handle
a number of common ref(expr) situations, if you pass the appropriate pieces of expr
as args. One could imagine automating this in various ways. E.g., treating ref
as a keyword and automatically detecting it in a module's AST and translating
the call to pick apart the passed expression suitably to make a call that
generates the refobj. But this is premature implementation ;-)

Let's get the requirements down first. One thing that pops up immediately
if you think about ref(namespace.name) vs ref(a[42]) is preservation of
the dynamic access semantics whose execution is deferred in time. I.e.,
a dangling pointer problem with additional twists.

If the essential ref infos are (namespace, name) and (a, 42), we must note that
we really implicitly made it
(namespace, ('__getattr__', '__setattr__', '__delattr__'), name)
and
(a, ('__getitem__', '__setitem__', '__delitem__'), 42)

(at least I did in the way I defined PNS, because deferred use of the refobj
to set a value implied doing getattr(namespace, name) at that time.
Accessor methods could also be bound at ref call time, with different semantics
resulting. I.e., we could have ref info stored as

((namespace.__getattr__, namespace.__setattr__, namespace.__delattr__), name)
and
((a.__getitem__, a.__setitem__, a.__delitem__), 42)

What is the real meaning desired for a refobj ? How should ref(42) be handled?
Should it become a legal refobj that only fails if used as assignment target,
so that it can be passed transparently to read-only users as well as references
to mutables that wind up only being used read-only?

Regards,
Bengt Richter

[Mike Meyer]

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Like having an assignment operator (let use @= for it) next to a
(re)bind operator.
We could then have something like the following.
a = 5
b = a
a @= 7
b ==> would result in 7.

You've just overwritten the object referred to by the token "5" in the
source code with the value 7, so you get:
print 5
7

You have a valid point, but I think a different approach is possible.
Don't make the distinction between mutable and immutable types but
between mutable and immutable objects. So an int wouldn't be an
immutable type, but 5 would be an immutable object.
So the code above I gave would throw an exception, but the following
might work.
a @= 5
b = a
b @= 7
a ==> would result in 7.

Which solves that issue but brings up - well, more issues. What
happens if the third line is 'b @= "seven"'? Does this require an
extra level of indirection in the implementation? Avoiding that kind
of thing was the reason for suggesting this:

Another approach is to have a special object type if you want to allow
assignment to the object it refers to. That's what Python does now, it
just doesn't have a syntax just to support that. If it did, your
example might look like:
a := 5
b = @a
a := 7
@b ==> would result in 7

Could it also work the other way? By somehow manipulating b change a?

It's intended to work the other way as well. But the second line is
wrong: it should have been "b = a". "b = @a" assigns b the value
referenced by a, and @b would then be an error. "b = a" assigns b to
the reference that is a, so that @b returns it's value.

The critical thing is that this doesn't introduce any new facilities
into the language, just some new syntax, so there's no implementation
impact. In fact, if you're willing to put up with some notational
abuse, we can do this now:

class Ref(object):
_unbound = object()
def __new__(cls, value = _unbound):
"""We're an object, but need to ignore the optional argument."""

return object.__new__(cls)

def __init__(self, value = _unbound):
"""Bind the optional value, if provided."""
if value is not self._unbound:
self._value = value

def __pos__(self):
"""Return value, if bound."""
try:
return self._value
except AttributeError:
raise ValueError, "%s object does not have a value stored." % \
self.__class__.__name__

def __iadd__(self, value):
self._value = value
return self

Usage:

x = Ref.Ref()
x += 23
+x 23 a = x
x += 25
+a 25 a += "this is a test"
+x

'this is a test'

Since it doesn't have real lannguage support, things like +x += 25
don't work. That's the only obvious gotcha. Maybe ~ would be a better
prefix.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Antoon Pardon]

Op 2005-11-15, Bengt Richter schreef <bo**@oz.net>:

On 15 Nov 2005 08:51:59 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2005-11-14, Bengt Richter schreef <bo**@oz.net>: [...]

You may be interested in reviewing

http://groups.google.com/group/comp....d3539e928986b3

before continuing this topic ;-)

It is a rather long thread. You want to avoid this one becomes of
comparable length?

Not necessarily. I just thought it might help in making new discussions
of previously discussed ideas clearer faster ;-)

Well I hope you are right. But I must confess I skimmed a number of
articles, there were just too many, to read them all in such a short
times.
Sometimes rehashing old topics seems just tedious, but sometimes someone
has a hunch that they are struggling to express, and they haven't yet succeeded
in communicating its essence. Then old discussions can sometimes serve
like first drafts of a speech, and revisions can prevent repeat of misunderstandings
that in the archived discussions one can see were inevitable. If the nascent idea comes out viable, we all benefit, and the tedium will have been
worth it. If not, well, then at least some ideas will have clearer form, and
the whole process will have been a social event that some will have enjoyed anyway ;-)

Well I certainly support that idea.

--
Antoon Pardon

[Antoon Pardon]

Op 2005-11-15, Bengt Richter schreef <bo**@oz.net>:

On 15 Nov 2005 08:51:59 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2005-11-14, Bengt Richter schreef <bo**@oz.net>: [...]

You may be interested in reviewing

http://groups.google.com/group/comp....d3539e928986b3

before continuing this topic ;-)

It is a rather long thread. You want to avoid this one becomes of
comparable length?

Not necessarily. I just thought it might help in making new discussions
of previously discussed ideas clearer faster ;-)

Well I hope you are right. But I must confess I skimmed a number of
articles, there were just too many, to read them all in such a short
times.
Sometimes rehashing old topics seems just tedious, but sometimes someone
has a hunch that they are struggling to express, and they haven't yet succeeded
in communicating its essence. Then old discussions can sometimes serve
like first drafts of a speech, and revisions can prevent repeat of misunderstandings
that in the archived discussions one can see were inevitable. If the nascent idea comes out viable, we all benefit, and the tedium will have been
worth it. If not, well, then at least some ideas will have clearer form, and
the whole process will have been a social event that some will have enjoyed anyway ;-)

Well I certainly support that idea.

--
Antoon Pardon