EuroPython 2006 and Py3.0

[Antoon Pardon]

On 2006-07-05, bearophileHUGS at lycos.com <bearophileHUGS at lycos.com> wrote:
> Kay Schluehr:
>> there is nothing really new or interesting or challenging.
>> Micro-optimizations and shape lifting.
>
> I see. Maybe Python is becoming a commodity used by more than 10e6
> persons, so changellenges aren't much fit anymore.
> Guido has tried to avoid the problems of Perl6, making Py3.0 a
> improvement and not a revolution. The good thing is that we'll probably
> see a beta version in 14-18 months. Py3.0 from being like fantasy is
> become something close, this is a good thing.
> I may ask you what you would like to see in Py3.0, but remember that
> your answer may become ignored by the developers.

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

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.


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


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.


-- 
Antoon Pardon