EuroPython 2006 and Py3.0

[Carl Banks]

In actual usage, though, how often is it strictly required one uses a
set over a list?

A lot. Perhaps you haven't personally encountered many use cases for
them, but I assure you that I and others have.

It is similar to how queue and stack are not in the
default namespace.

Not really. set has proven itself to be more generally useful than the
other containers; that's why it was promoted to builtin only one
release after it was added to the standard library. (IIRC, people on
this list were not very enthusiastic about it, since a dict could cover
some (not all) of the use cases, but it kind of won people over.)

Unless you really need to ensure no one is allowed
to make random access changes to your data, a list with push and pop is
really all you need.

No it isn't. There are several things sets are signifcantly better
than lists at:

1. A set ensures there are no duplicate items, which is often very
important.

2. Membership testing. "a in b" is O(N) if b is a list, but O(1) if b
is a set. What this means is, on average, testing whether an item is
in a list is roughly proportional to the length of the list, whereas
testing whether an item is in a set is roughly constant, no matter how
big the set it. If you have thousands of items in your collection,
using a list is really going to slow things down.

3. Set operations: union, intersection, difference. I use sets a lot,
but these operations not as often. However, when the need for them
comes up, these methods are absolutely indispensable.

Again, maybe you don't encounter the need for them in your programming
(or perhaps you do and aren't aware of how sets could help), but many
people use them a lot.


Carl Banks

 

[Antoon Pardon]

Antoon,

First of all there is a distinction between ordered and un-ordered data
types. You can only slice ordered data types. Lists and tuples are
ordered while the keyset (note the _set_ part) of a dictionary is a set
- it is un-ordered and consists of unique elements, the keys.

That doesn't has to be. Let as talk about a mapping. A mapping is
a way to associate a key with a value. Now one way to implement
a mapping is a hash table, this is how python dictionaries
are implemented.

Now I have an other mapping implementation, look at:

http://www.pardon-sleeuwaegen.be/antoon/avltree.html

Now this mapping type has as a property that the order
of the keys is somehow stored with it, so that each
time you call the keys, values, or items methods, you
will get a list according the order of the keys. (The
same goes for the itervariants).

Besides, I don't really understand what you mean by saying "a tree acts
like a dictionary"? You don't really iterate over the dictionary
because the keys are not in order! Remeber that. The confusing part is
that ks=dic.keys() will return a list so that makes you think ks[0] is
somehow first for some reason, but it shouldn't be.

My module is implemented to have that property. It is called a tree
because the implementation is a tree. May be with the API provided
you think a tree is not a good name for this class and you may
have a point there, but that is not what this discussion is about.

You see, dictionaries were there in Python before sets(), that is why
when sets are supposed to be used a dictionary or list is used. keys()
is one of these example. Hopefully this will change in P3K so that the
key_set_ of a dictionary is a set() so people don't get confused.

And what do you think should be the result of keys of my Tree class?

 

[Antoon Pardon]

I keep thinking that means changing the meaning of "slice"

Why? This doesn't need any new functionality of slice. I already
can have this behaviour, but just would have to write it as follows:

for k, v in t.items(slice('a','b')):

This is just a question of literal slice notation. Do we
limit the notation of a:b to indexing and for the slice(a,b)
notation everywhere else or do we allow the a:b notation for
a slice in other places where it seems usefull.

Slicing and indexing is inside square brackets. (start:stop) seems
confusing to me.

The notation is just start:stop the parenthesis will in practice
be added often to avoid disambiguities, like with the compound
statements when the colon is also used to start a suite, a bit
like tuples where parenthesis are often added too, although
they are not really needed to form a tuple literal.

And I seriously doubt that Guido or someone on his
behalf will go through introducing another syntax for something that can
be already done in one way. I came to Python because of it's clean
syntax and I've always tought "one good way to do one thing" is better
than Perlish style. That's why I don't like powering up slice objects to
do that.

My proposal will make the python syntax cleaner. Now you have
slices in python. The general way to have a slice is:

slice(start, stop, step)

But in one particular place, when used as an index you are allowed
to write that slice as:

start:stop:step

lst[start:stop:step] is just another way of writing lst[slice(start,stop,step)]

In my opionion that is not very clean. The first part of my proposal
entail no powering up whatsoever. It is just a proposal to make
the syntax of python more clean, so that the start:stop:step notation
for a literal slice is available everywhere, where a literal can
occur, instead of only in one particular place.

I'm not the person in charge to make decisions about Python syntax,
power and limitations but I really don't see a useful use case to have a
slice++. Even decorators (that few people really understand) have a lot
of use cases more than slice++

You should look at my points as different proposals. I think each
proposal is usefull in its own way. Allow the priveleged synax
for indexing anywhere is usefull even if nothing else is accepted.
Allowing slice to be subclassed is usefull even of nothing else is
accepted. It is not a package deal that is to be accpeted or rejected
as a whole.

I understand. So maybe asking for subclassable slices is better

Well that was one of the things I proposed.

 

[Steve Holden]

Steve,

What does a 'connection to the language' mean? Does it mean 'using' it
for years or 'being involved in its actual development' for years? It
seems that sometimes a newcomer can actually bring in a fresh idea.
What new users think and what bothers them is actually important. The
reason Python became so popular is because it attracted so many new
users. If anyone has a reasonable suggestion, let them post it to this
group, see what the reaction is, then let them write a proposal in the
right format using all the procedures and all. Looking forward to
Python 3000 this is the time to do it. Rejections do take time but they
will just have to happen, out of 10 rejected maybe there will be one
good proposal that will make Python a little better.

I have no objection to anyone posting in this group, but the Py3k list
is about the future of the language. For Python to remain Python it need
to retain precisely those characteristics that have seen it rise to its
current popularity. While new ideas are a good thing it would be
completely inappropriate to produce a language that no longer seems
"Pythonic". In order to retain pythonicity, therefore, it seems to me
that those who decide nt he future of the language should have at least
*some* practical experience of a) language design and b) Python.


regards
Steve