First of all, thanks to those who showed interest in the subject and
replied to my question.
Please consider the following as an academic exercise. Actually I am
reasonably happy with the current way things are done in Python. Only
that I am curious to see whether Tuples and Lists could be combined into
a single data type, with some additional behind the curtains processing.
Let's say that it has been decreed that a single data type serve as both
Tuple and List. How would it be specified and implemented?
First of all, let's use only square brackets [] to represent literals.
The parentheses () will be reserved for function and class method calls.
It may be possible to optionally prefix the brackets with a character
signifying whether the data structure is mutable or not - like the r and
u prefixes of string literals:
m[1,2,3] - mutable List
i["a","y","\u2034"] - immutable (would be Tuple in today's Python)
On Wed, 2008-06-11 at 16:03 +0300, Adi Stav wrote:
> I'm not sure what you are suggesting?
>
> 1. Not having tuples, only lists. And then you wouldn't be able to use lists
> or tuples as dict keys, and wouldn't be able to do tuple assignment
Tuple assignments can still be done - instead of considering
x, y = y, x
as implicit
(x,y) = (y,x)
we'll consider it as implicit
[x,y] = [y,x]
> 2. Not having lists, only tuples. And then you would be able to use them as
> dict keys all you want, but you wouldn't be able to modify their members in
> place.
Like there are (immutable) strings and (mutable) buffers, the data
structure will be marked as either immutable or mutable. If an
immutable data structure needs to be modified, a shallow copy will be
automatically performed on it and the copy will be the one to be
modified. This is what happens when you invoke list() on a Tuple in
current Python.
To illustrate it further, let's follow the life cycle of a data
structure.
x = [1.1,2.2,4.5,"e"]
It is marked as mutable, as it has no reference which expects it to be
immutable.
y = { x : "Emu", 42 : "Gnu" }
Now, the value of x has a reference which expects it to be mutable and a
reference which expects it to be immutable. So the value is flagged as
immutable.
x[1] += 0.1
Since the value of x is marked as immutable, the above operation copies
it and modifies the copy. The value serving as hash key is now
referenced only by the Dict (and stays immutable), and the value
referenced by x is a new copy - and marked as mutable until and unless
referenced by someone who expects it to be immutable.
z = x + [lambda v: v+1]
Now, x refers to the [0:4] slice of the list, while z refers to the
entire list. (NOTE: this point can be debated - do we alter the value of
x or do we create a copy and assign to z a modified copy?)
> 3. Have both both tuples and lists, but have a different syntax for handling
> them than Python currently has.
I am not interested in such a trivial change.
> On Wed, 2008-06-11 at 16:34 +0300, Oren Tirosh wrote:
> Yes, the only technical difference is that tuples are immutable. For
> me that's enough of a raison d'etre for tuples. Indexing dictionaries
> by a combination of keys is quite useful. Sets of tuples even more. I
> actually used that yesterday.
I agree that it is very useful to use sequences (Tuples/Lists) as Dict keys. I
myself use this technique.
> The other difference is more subtle. When you write 'return x,y' you
> think of your function as returning two values, not a single value
> that is a sequence of length 2. And when you type 'a, b = b, a' you
> think of swapping values, not packing and unpacking of sequences. Not
> having to type parentheses in most of these cases helps keep this
> illusion and I find that it makes python source code more beautiful.
It is possible not to have to type square brackets in the same way (see above).
> Beauty matters. Source code is a form of communication with other
> human beings.
I agree. However, implicit in my argument is the claim that beauty may be
enhanced by dropping one redundant notation, namely that of Tuples as distinct
from Lists.
Reasonable people can disagree about this, however.
> When you use a tuple, the fixed length carries the
> implicit connotation that each position has a specific role "first is
> x coordinate, second is y". "first is name, second is value", etc.
If this is important, then use a class and give names to the positions.
point.x,point.y,point.z would be more intuitive than point[0],point[1],point[2].
If brevity of notation is more important than intuitiveness (you just want to
go on with coding rather than declare a small class), then List is as good.
> When your reader sees the square brackets, you are signalling that
> "this is a sequence of essentially uniform items. Specific positions
> do not carry specific meanings although order might matter. The length
> of this list is expected to change between subsequent executions of
> the same piece of code or even during the lifetime of the specific
> list object".
I would use the way the data structure is operated upon as clue for its
meaning. If you invoke append() on it, then it obviously has the connotation
of the current Python's List.
--- Omer
--
You haven't made an impact on the world before you caused a Debian
release to be named after Snufkin.
My own blog is at http://www.zak.co.il/tddpirate/
My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
_______________________________________________
Python-il mailing list
[email protected]
http://hamakor.org.il/cgi-bin/mailman/listinfo/python-il
