General question about Python design goals

[Fredrik Lundh]

I'm sure Antoon wouldn't object if lists were to be allowed as
dictionary keys, which would eliminate the multiple castings for
that situation. I wouldn't, either.

so what algorithm do you suggest for the new dictionary im-
plementation?

</F>

 

[Christoph Zwerschke]

This is one of those little things that happens in language evolution;
not everything gets done right the first time. But Python is developed
by volunteers: if you want this fixed, the first step is to submit a bug
report on SF (or go ahead and submit a patch if you have the expertise).
(I'm quite comfortable channeling Guido and other developers in saying a
patch will get accepted.)

Ok, I submitted it as feature request #1370948. I currently don't have
the time and expertise to submit a patch.

-- Christoph

 

[Rick Wotnaz]

so what algorithm do you suggest for the new dictionary im-
plementation?

Beats the heck outta me. I seem to remember that Antoon supplied
one awhile ago (for allowing lists to serve as dictionary keys,
that is). That's why I mentioned him in the first place. I didn't
pay much attention to it at the time, and I imagine it would raise
some issues, like everything does.

I'm fairly indifferent to the idea in any case; I'm just saying I
wouldn't object if lists could function as dictionary keys. It
would save that casting step I was talking about.

 

[Alex Martelli]

Presumably because it's necessary to extract the individual values
(though os.stat results recently became addressable by attribute name as
well as by index, and this is an indication of the originally intended
purpose of tuples).

Yep -- "time tuples" have also become pseudo-tuples (each element can be
accessed by name as well as by index) a while ago, and I believe there's
one more example besides stats and times (but I can't recall which one).

Perhaps, if the tuple type _in general_ allowed naming the items in a
smooth way, that might help users see a tuple as "a kind of
``struct''... which also happens to be immutable". There are a few such
"supertuples" (with item-naming) in the cookbook, but I wonder if it
might not be worth having such functionality in the standard library
(for this clarification as well as, sometimes, helping the readability
of some user code).


Alex

 

[Fredrik Lundh]

Beats the heck outta me. I seem to remember that Antoon supplied
one awhile ago (for allowing lists to serve as dictionary keys,
that is).

anyone has a pointer? all I can remember is that people have posted
various "if the key is mutated, I don't care if the value can no longer
be found" proposals (besides the usual SEP variants, of course), but
Antoon's endless stream of "I claim that it be argued that" posts
makes it easy to miss things...

</F>

 

[Christoph Zwerschke]

kook.

Thanks.

Just to clarify: I was referring to the weakness of the argument
"tuple.count() is evil" when I wrote "telling". It was not meant
derogatory towards your person in any way - if you understood it that
way I apologize. Maybe I write in a way that can be easily
misunderstood, but I would not deliberately libel others, least of all
if it is only about a petty issue of a programming language.

-- Christoph

 

[Fredrik Lundh]

Yep -- "time tuples" have also become pseudo-tuples (each element can be
accessed by name as well as by index) a while ago, and I believe there's
one more example besides stats and times (but I can't recall which one).

Perhaps, if the tuple type _in general_ allowed naming the items in a
smooth way, that might help users see a tuple as "a kind of
``struct''... which also happens to be immutable". There are a few such
"supertuples" (with item-naming) in the cookbook, but I wonder if it
might not be worth having such functionality in the standard library
(for this clarification as well as, sometimes, helping the readability
of some user code).

iirc, providing a python-level API to the SequenceStruct stuff
has been proposed before, and rejected.

(fwiw, I'm not sure the time and stat tuples would have been
tuples if the standard library had been designed today; the C-
level stat struct doesn't have a fixed number of members, and
the C-level time API would have been better off as a light-
weight "time" type (similar to sockets, stdio-based files, and
other C-wrapper types))

</F>

 

[Rocco Moretti]

Rick Wotnaz wrote:



so what algorithm do you suggest for the new dictionary im-
plementation?

<devil's_advocate> One option is to create a new "frozen list" type, a`
la frozen sets.


People who argue that "frozen list" is not needed because we already
have the tuple type, while simultaneously arguing that tuples shouldn't
grow list methods because they are conceptually different from lists
will be bludgeoned to death with a paradox. </devil's_advocate>

 

[Fredrik Lundh]

<devil's_advocate> One option is to create a new "frozen list" type, a`
la frozen sets.

doesn't frozenset make a copy?

People who argue that "frozen list" is not needed because we already
have the tuple type, while simultaneously arguing that tuples shouldn't
grow list methods because they are conceptually different from lists
will be bludgeoned to death with a paradox.

http://www.python.org/peps/pep-0351.html

This PEP describes a simple protocol for requesting a frozen,
immutable copy of a mutable object. It also defines a new
built-in function which uses this protocol to provide an
immutable copy on any cooperating object.
...

Here are some code samples which show the intended semantics

class xset(set):
def __freeze__(self):
return frozenset(self)

class xlist(list):
def __freeze__(self):
return tuple(self)

...

</F>

 

[Rocco Moretti]

doesn't frozenset make a copy?

As does the current "cast as tuple" technique. (I'm certainly not
advocating it, but ...) Certain implementations of "frozen list" could
possibly do the list->frozenlist conversion without a copy. (e.g. by
flipping an "immutable" bit)

http://www.python.org/peps/pep-0351.html

This PEP describes a simple protocol for requesting a frozen,
immutable copy of a mutable object.

Perhaps Barry has been borrowing Guido's time machine?

 

[Antoon Pardon]

Mike Meyer wrote:


So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work?

because the syntax says so:

http://docs.python.org/ref/for.html


Seriously. Why doesn't this have to be phrased as "for x in list((1,
2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?

because anything that supports [] can be iterated over.

This just begs the question. If tuples are supposed to be such
heterogenous sequences, one could indeed question why they
support [].

Presumably because it's necessary to extract the individual values

It isn't, The stated intent of tuples seems to suggest that packing
and unpacking should be sufficient.

(though os.stat results recently became addressable by attribute name as
well as by index, and this is an indication of the originally intended
purpose of tuples).

And even if good arguments are given why tuples shouls support
[], the fact that the intention of tuples and list are so
different casts doubts on the argument that supporting []
is enough reason to support iteration.

One could equally also argue that since iteration is at the heart
of methods like index, find and count, that supporting iteration
is sufficient reason to support these methods.

One could even go so far as to prepare a patch to implement the required
methods and see if it were accepted (though wibbling is a much easier
alternative).

That has been done and it was rejected.

Personally I find the collective wisdom of the Python
developers, while not infallible, a good guide as to what's pythonistic
and what's not. YMMV.

That's because their decisions will shape python and thus decide
what is pythonic and what is not.

 

[Mike Meyer]

because the syntax says so:
http://docs.python.org/ref/for.html

In other words, "Because that's the way we do things."

Seriously. Why doesn't this have to be phrased as "for x in list((1,
2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?

because anything that supports [] can be iterated over.

That's false. Anything that has __getitem__ supports []. To be
iterated over, it has to have __iter__, or an __getitem__ that works
on integers properly. Writing a class that meets the first without
meeting the second is easy. Dicts used to qualify, and tuples could be
iterated over at that time.

Not really very satisfactory reasons.

<mike

 

[Donn Cave]

iirc, providing a python-level API to the SequenceStruct stuff
has been proposed before, and rejected.

(fwiw, I'm not sure the time and stat tuples would have been
tuples if the standard library had been designed today; the C-
level stat struct doesn't have a fixed number of members, and
the C-level time API would have been better off as a light-
weight "time" type (similar to sockets, stdio-based files, and
other C-wrapper types))

Right. After devoting a lengthy post to the defense of
tuples as a structured type, I have to admit that they're
not a very good one - it's hard to think of many structured
values that are ideally expressed by a fixed length vector
with elements accessed by integer index.

Another theme that occasionally comes up in advice from the
learned has been "use a class". Of course for values that
are related to some external structure, you'd want to provide
something to make tuple(a) work, serialization etc., and you'd
probably end up with something a lot like StructSequence.
Meanwhile losing a significant overhead.

I wrote a quickie Python API to SequenceStruct and used it to
make an (x, y) coord type, to compare with a Coord.x,y class.
A list of a million coords used 1/5 space, and took 1/10 the
time to create. Hm.

Donn Cave, (e-mail address removed)

 

[Donn Cave]

People who argue that "frozen list" is not needed because we already
have the tuple type, while simultaneously arguing that tuples shouldn't
grow list methods because they are conceptually different from lists
will be bludgeoned to death with a paradox. </devil's_advocate>

Maybe I can dodge the paradox by noting that the set of things
we need, is much larger than the set of things we need enough
to do what it takes to get them. So I can agree that frozen
lists are needed, without necessarily supporting the effort.

Donn Cave, (e-mail address removed)

 

[Donn Cave]

....

So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work?

Seriously. Why doesn't this have to be phrased as "for x in list((1,
2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?

How could list(t) work, if for x in t didn't?
For me, conceptually, if an object can't be accessed
sequentially, then it can't be mapped to a sequence.

Anyway, it seems to me that in the end this is about
that balance between practicality and purity. Maybe
it's more like tuples have a primary intended purpose,
and some support for other applications. Not white,
but not pure black either.

Donn Cave, (e-mail address removed)

 

[Fredrik Lundh]

Seriously. Why doesn't this have to be phrased as "for x in list((1,
2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?

because anything that supports [] can be iterated over.

That's false. Anything that has __getitem__ supports []. To be
iterated over, it has to have __iter__, or an __getitem__ that works
on integers properly.

your arguments are getting more and more antoon-like. you can create
an iterator (using iter) for any object that supports [] (__getitem__), but
if __getitem__ doesn't do the right thing, any attempt to fetch items by
calling it will of course fail as well.

Writing a class that meets the first without
meeting the second is easy. Dicts used to qualify, and tuples could be
iterated over at that time.

Not really very satisfactory reasons.

that's how python's sequence protocol works. duck typing all the
way down.

http://www.google.com/search?q=duck+typing

</F>

 

[Paul Rubin]

Right. After devoting a lengthy post to the defense of
tuples as a structured type, I have to admit that they're
not a very good one ...
Another theme that occasionally comes up in advice from the
learned has been "use a class".

There's a historical issue too: when tuples started first being
used this way in Python, classes had not yet been introduced.

 

[Donn Cave]

There's a historical issue too: when tuples started first being
used this way in Python, classes had not yet been introduced.

When was that, old-timer? According to Misc/HISTORY,
Python was first posted to alt.sources at version 0.9.0,
February 1991. It doesn't say 0.9.0 had classes, but
at 0.9.3 we see refinements like __dict__, and it's hard
to imagine that classes themselves snuck in without notice
in the interim.

If you got a copy of some older version than this, you
have some interesting historical perspectives there, but
not much of a historical issue, I'd say, without much
going on in the way of a user community.

Donn Cave, (e-mail address removed)

 

[Fredrik Lundh]

When was that, old-timer? According to Misc/HISTORY,
Python was first posted to alt.sources at version 0.9.0,
February 1991. It doesn't say 0.9.0 had classes, but
at 0.9.3 we see refinements like __dict__, and it's hard
to imagine that classes themselves snuck in without notice
in the interim.

If you got a copy of some older version than this, you
have some interesting historical perspectives there, but
not much of a historical issue, I'd say, without much
going on in the way of a user community.

fwiw, the tuple and class implementation were both checked into
CVS in october 1990.

maybe he's talking about ABC ? (where, judging from the language
reference, had lists, compounds, and tables which worked pretty
much like Python's lists, tuples, and dictionaries).

</F>

 

[Mike Meyer]

Seriously. Why doesn't this have to be phrased as "for x in list((1,
2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?
because anything that supports [] can be iterated over.

That's false. Anything that has __getitem__ supports []. To be
iterated over, it has to have __iter__, or an __getitem__ that works
on integers properly.

your arguments are getting more and more antoon-like. you can create
an iterator (using iter) for any object that supports [] (__getitem__), but
if __getitem__ doesn't do the right thing, any attempt to fetch items by
calling it will of course fail as well.

So you're claiming that the ability to create an iterator for an
object via iter is sufficient to claim that you can iterate over it,
never mind that actually using the iterator fails?

Or are you claiming that a __getitem__ that doesn't handle integers
the way iter expects is somehow "wrong"? If so, what's up with
dict.__getitem__?

If you're claiming something else, you'll have to clarify it.

that's how python's sequence protocol works. duck typing all the
way down.
http://www.google.com/search?q=duck+typing

So it's an accident of implementation? Should iterating over a tuple
then be considered "abuse", because tuples aren't intended to be used
as a sequence?

I'm perfectly happy to accept that tuples aren't sequences, and that's
why they don't have sequence-like methods. But there really should be
a better explanation than "oops" for them having sequence-like
behavior elsewhere.

<mike