EuroPython 2006 and Py3.0

[Lawrence Oluyede]

Re: EuroPython 2006 and Py3.0

Antoon Pardon <apardon@forel. vub.ac.bewrote:

I have a tree class, a tree acts like a dictionary, but when you
iterate over it, it always iterates over the keys in order. This
makes it usefull to iterate over a slice. So it would be usefull
if methods like keys, values and items could take a slice as
an argument and use the same notation for it. Something like
>
for k, v in t.items('a':'b' ):
>
Which would iterate over all items where the key starts with
an 'a'.

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

-1. First: you have to introduce new syntax for an old thing.

>
That syntax already exists, it just is only available as an
index.

Slicing and indexing is inside square brackets. (start:stop) seems
confusing to me. 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.

Range as it is, is going to disappear. Last time I read the
python 3000 Pep range would get the functionality of xrange
and xrange would disappear, and those who want a list will
have to do: list(range(a,b) )

Yep but generators are better to iterate. list(range_obje ct) is less
common than for i in range_object AFAIK

Need is such a strong word. In the end we don't need python, but
it seems very usefull to have it around. I understand that should this
be introduced it could make people uneasy, but I also think it
could be very usefull.

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++

Because it would have made things a lot of easier for me in
a number of cases. I have a table class that is like a
list but can start at any index, it sure would have been
easier to write with some of the possibilities above. I
though to just write my own slice class, but slice is not
subclassable, and when I just wrote my own from scratch,
with a start, stop and step attribute I got an error that
it wasn't an integer so couldn't be used as an index.
So much for duck taping.

I understand. So maybe asking for subclassable slices is better :-)


--
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

[Lawrence Oluyede]

Re: EuroPython 2006 and Py3.0

A.M. Kuchling <amk@amk.cawrot e:

If Python 3000 turns into a let's-try-all-sorts-of-goofy-new-ideas
language, at least some of those ideas will turn out to have been
mistakes, and then we'll need a Python 3000++ to clean things up.

And I also think "we" will lose some developers in the community. Python
is good because is flexible and it's tight to the need of people who
write code for passion, work and educational purposes (that's another
meaning of "multiple purposes language"). If Python turns to be only an
educational language... it will definitely fail.

--
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

[Nick Vatamaniuc]

Re: EuroPython 2006 and Py3.0

That is why we have PEPs and people who read forums and, of course,
GvR.

At this point it seems that Python is mainstream enough that it
probably shouldn't be modified too much but it is also 'fresh' enough
to accept some modifications and new ideas.

The bottom line is that the more people are involved the better. Some
will suggest crazy new stuff that they might have seen in ML or C# and
there will be others who will tell them they are way out there and
Python doesn't need that stuff. In other words we need bold inovators
and more conservative people. After some debate and discussion a
reasonable, good middle ground will be reached.

Regards,
Nick V.

A.M. Kuchling wrote:

On Fri, 14 Jul 2006 18:45:07 +0200,
Fredrik Lundh <fredrik@python ware.comwrote:

bearophileHUGS@ lycos.com wrote:

This attitude may have some downsides. The Python developers don't know
everything, other people can have some experience of computer languages
too.

"some experience of computer languages" != "experience of language
design and implementation"

as long as most of the traffic on py3k is bikeshed stuff and hyper-
generalizations , most people who do hard stuff will spend their time
elsewhere.

>
Paul Prescod once wrote in c.l.py:
>
If Python strays into trying to be something completely new it will
fail, like Scheme, K and Smalltalk. There are both technical and
sociological reasons for this. If you stray too far technically, you
make mistakes: either you make modelling mistakes because you don't
have an underlying logical model (i.e. C++ inheritance) or you make
interface mistakes because you don't understand how your new paradigm
will be used by real programmers.
>
Let research languages innovate. Python integrates.
>
If Python 3000 turns into a let's-try-all-sorts-of-goofy-new-ideas
language, at least some of those ideas will turn out to have been
mistakes, and then we'll need a Python 3000++ to clean things up.
>
--amk

[Nick Vatamaniuc]

dict = no ordered keys = no slicing

>I have a tree class, a tree acts like a dictionary, but when you

iterate over it, it always iterates over the keys in order.

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.

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.

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.

As far as the tree goes, I still don't see how you would apply the
slice operator to the tree. You can traverse the tree in-order,
pre-order or post-order so how does slicing fit in there.

Hope this helps,
Nick Vatamaniuc


Antoon Pardon wrote:

On 2006-07-14, Lawrence Oluyede <rhymes@myself. comwrote:

Antoon Pardon <apardon@forel. vub.ac.bewrote:

These are just some ideas. Whether they fit into python or not I will
leave to the developers.

I'm not a Python pro. but:

1) Literal slices, in a sense we already have these, but they are
limited to indexing. You can't do something like fun(::). May
be this means the notation used now has to be adapted.

I don't see the use case for this.

>
You don't think it usefull that when you need a slice as an argument
you can use the same notation as when you use when you need a
slice as an index?
>
I have a tree class, a tree acts like a dictionary, but when you
iterate over it, it always iterates over the keys in order. This
makes it usefull to iterate over a slice. So it would be usefull
if methods like keys, values and items could take a slice as
an argument and use the same notation for it. Something like
>
for k, v in t.items('a':'b' ):
>
Which would iterate over all items where the key starts with
an 'a'. Sure you don't need it. You could just use
>
for k, v in t.items(slice(' a','b')):
>
or you could define the items method with the same signature
as range or xrange. But it seems appropiate that the same
notation can be used anywhere.
>

2) Iterable slices. Allow (provided the slice notation stays:)
>
for i in (1:10):
...
>
to do the same as:
>
for i in xrange(1,10):
>
This will allow to get rid of both range and xrange. Xrange
is totally unnecessary and range(a,b) becomes list(a:b).

-1. First: you have to introduce new syntax for an old thing.

>
That syntax already exists, it just is only available as an
index.
>

Second:
you overload the meaning of slicing and the slice operator and so on.

>
It's meaning is not overloaded, it just gets extra functionality.
>

range is perfectly integrated and the right tool for the job.

>
Range as it is, is going to disappear. Last time I read the
python 3000 Pep range would get the functionality of xrange
and xrange would disappear, and those who want a list will
have to do: list(range(a,b) )
>

There's no
need to introduce new syntax to iterate over a range of integers.

>
Need is such a strong word. In the end we don't need python, but
it seems very usefull to have it around. I understand that should this
be introduced it could make people uneasy, but I also think it
could be very usefull.
>

4) Introduce Top and Bottom objects, which will allways
compare greater/smaller to other objects. Make them
the default values for the start and stop values of
slices.
5) Give slices a "&" and "|" operator.
>
>
7) Give slices the possibility to include the stop value.
>
My first idea here was that the notation of slices
was adapted, so that what is a:b now would become
a:|b. A slice to include the b would then be a::b.
You could even have a slice that didn't include the
a but included the b like: a|:b
>
Now I expect a lot of resitance here, so it this
seems not feasable, just drop it.
>
6) Is this is all asked too much, make slice at least
subclassable.

Why do you need power slices?

>
Because it would have made things a lot of easier for me in
a number of cases. I have a table class that is like a
list but can start at any index, it sure would have been
easier to write with some of the possibilities above. I
though to just write my own slice class, but slice is not
subclassable, and when I just wrote my own from scratch,
with a start, stop and step attribute I got an error that
it wasn't an integer so couldn't be used as an index.
So much for duck taping.
>
But if this idea doesn't catch on, so be it.
>
--
Antoon Pardon

[Carl Banks]

Re: {} for set notation

tac-tics wrote:

Nick Vatamaniuc wrote:

I really like the set notation idea. Now that sets are first class
"citizens" along with dicts, lists and tuples I think they should be
used when it makes sense to use them

>
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]

Re: dict = no ordered keys = no slicing

On 2006-07-14, Nick Vatamaniuc <vatamane@gmail .comwrote:

>>I have a tree class, a tree acts like a dictionary, but when you
>iterate over it, it always iterates over the keys in order.

>
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

[Antoon Pardon]

Re: EuroPython 2006 and Py3.0

On 2006-07-14, Lawrence Oluyede <rhymes@myself. comwrote:

Antoon Pardon <apardon@forel. vub.ac.bewrote:
>

>I have a tree class, a tree acts like a dictionary, but when you
>iterate over it, it always iterates over the keys in order. This
>makes it usefull to iterate over a slice. So it would be usefull
>if methods like keys, values and items could take a slice as
>an argument and use the same notation for it. Something like
>>
> for k, v in t.items('a':'b' ):
>>
>Which would iterate over all items where the key starts with
>an 'a'.

>
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.

-1. First: you have to introduce new syntax for an old thing.

>>
>That syntax already exists, it just is only available as an
>index.

>
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,sto p,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.

>Need is such a strong word. In the end we don't need python, but
>it seems very usefull to have it around. I understand that should this
>be introduced it could make people uneasy, but I also think it
>could be very usefull.

>
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.

>Because it would have made things a lot of easier for me in
>a number of cases. I have a table class that is like a
>list but can start at any index, it sure would have been
>easier to write with some of the possibilities above. I
>though to just write my own slice class, but slice is not
>subclassable , and when I just wrote my own from scratch,
>with a start, stop and step attribute I got an error that
>it wasn't an integer so couldn't be used as an index.
>So much for duck taping.

>
I understand. So maybe asking for subclassable slices is better :-)

Well that was one of the things I proposed.

--
Antoon Pardon

[Steve Holden]

Re: EuroPython 2006 and Py3.0

Nick Vatamaniuc wrote:

>>The real problems with the Py3k list seem to be associated with a number
>>of people who, despite having had little apparent connection to the
>>language until now, have joined the list and started making
>>inappropria te suggestions, which then have to be (patiently) rejected.

>
>
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden