EuroPython 2006 and Py3.0

Discussion in 'Python' started by bearophileHUGS@lycos.com, Jul 5, 2006.

  1. Guest

    >From this interesting blog entry by Lawrence Oluyede:
    http://www.oluyede.org/blog/2006/07/05/europython-day-2/
    and the Py3.0 PEPs, I think the people working on Py3.0 are doing a
    good job, I am not expert enough (so I don't post this on the Py3.0
    mailing list), but I agree with most of the things they are agreeing
    to. Few notes:

    - input() vanishes and raw_input() becomes sys.stdin.readline(). I
    think a child that is learning to program with Python can enjoy
    something simpler: input() meaning what raw_input() means today.


    - dict.keys() and items() returns a set view

    This is being discussed here too a lot, I agree that they will just
    become equivalent to iterkeys() and iteritems().


    - dict.values() a bag (multiset) view

    I think this isn't a good idea, I think bags can be useful but in this
    situation they make things too much complex.


    http://www.python.org/dev/peps/pep-3100/#core-language :
    - Set literals and comprehensions: {x} means set([x]); {x, y} means
    set([x, y]). {F(x) for x in S if P(x)} means set(F(x) for x in S if
    P(x)). NB. {range(x)} means set([range(x)]), NOT set(range(x)). There's
    no literal for an empty set; use set() (or {1}&{2} :). There's no
    frozenset literal; they are too rarely needed.

    I like the idea of set literals, but using {1:2} for dicts and {1, 2}
    for sets may look a bit confusing.
    And using {} for the empty dict is confusing even more, newbies will
    use it a lot for empty sets. Maybe the {:} for the empty dict and {}
    for the empty set are a bit better.
    Maybe a better syntax can be use a different denotator, to distinguis
    the two structures better. Some possibilities are nice looking but not
    easy to type:
    «1, 2»
    Other may be confused with bitwise operators:
    |1, 2|
    Others are bad looking and not easy to type (some nationalized
    keyboards don't have the `):
    §1, 2§
    `1, 2`
    Some of them are too much long:
    <<<1, ,2>>>
    Maybe using two nested like this is better (you can't put a dict or set
    in a set, so there are no ambiguities):
    {{1, 2}}

    I don't have a definitive good solution, but I think that adopting a
    bad solution is worse than using set(...). Set literals are cute but
    not necessary. Choosing things that increase the probability of bugs
    isn't good.

    ---------------------

    In the past I have suggested other possibilities for Py3.0, nothing
    really important, but few things can be interesting.

    - cmp() (or comp(), comp4(), etc) returns 4 values (<, ==, >, not
    comparable).
    - do - while.
    - NOT OR AND XOR as bitwise operators syntax.
    - Better syntax for octals and hex numbers.
    - obj.copy() and obj.deepcopy() methods for all objects.
    - Simplification and unification of string formatting (I have seen they
    are working on this already).
    - Intersection and subtraction among dicts.

    Less important things:
    - More human syntax for REs
    - Optional auto stripping of newlines during an iteration on a file.
    - String split that accepts a sequence of separators too.
    - a function in the math library to test for approximate FP equality.
    - something in cmath to do a better conversion of polar<->cartesian
    complex number conversion
    - xpermutations and xcombinations generators in the standard library.

    Bye,
    bearophile
    , Jul 5, 2006
    #1
    1. Advertising

  2. enlightened us with:
    > I like the idea of set literals, but using {1:2} for dicts and {1,
    > 2} for sets may look a bit confusing.


    I agree with you. Curly brackets are used for dicts, and using them
    for sets too is confusing. I know I will get confused every now and
    then, and I've got a Bachelor degree in Computer Science...

    > And using {} for the empty dict is confusing even more, newbies will
    > use it a lot for empty sets. Maybe the {:} for the empty dict and {}
    > for the empty set are a bit better.


    Still too much confusion IMO.

    > Maybe a better syntax can be use a different denotator, to distinguis
    > the two structures better. Some possibilities are nice looking but not
    > easy to type:
    > «1, 2»


    I guess « and » are difficult to type on many systems. I just press
    Compose, <, < to get «, but on other systems it'll be difficult.

    > Maybe using two nested like this is better (you can't put a dict or
    > set in a set, so there are no ambiguities): {{1, 2}}


    But you can put a set in a dict...

    > I don't have a definitive good solution, but I think that adopting a
    > bad solution is worse than using set(...). Set literals are cute but
    > not necessary. Choosing things that increase the probability of bugs
    > isn't good.


    I fully agree with you.

    > - Better syntax for octals and hex numbers.


    Would be nice to have binary numbers to! Something like 0b111000 for
    instance.

    Sybren
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
    Sybren Stuvel, Jul 5, 2006
    #2
    1. Advertising

  3. Guest

    Sybren Stuvel:
    > But you can put a set in a dict...


    Only as values, not as keys, because sets are mutable.

    Bye,
    bearophile
    , Jul 5, 2006
    #3
  4. Kay Schluehr Guest

    wrote:
    > >From this interesting blog entry by Lawrence Oluyede:

    > http://www.oluyede.org/blog/2006/07/05/europython-day-2/
    > and the Py3.0 PEPs, I think the people working on Py3.0 are doing a
    > good job, I am not expert enough (so I don't post this on the Py3.0
    > mailing list), but I agree with most of the things they are agreeing
    > to.


    No one expected them to do a bad job, but there is nothing really new
    or interesting or challenging. Micro-optimizations and shape lifting.
    Even a small discussion about the frictions of pattern matching and OO
    with Martin Odersky, one of the creators of the Scala language, is more
    inspiring than reading the whole Py3K stuff. I decided not to attend to
    EuroPython this year...
    Kay Schluehr, Jul 5, 2006
    #4
  5. Guest

    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.

    Bye,
    bearophile
    , Jul 5, 2006
    #5
  6. Steve Holden Guest

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

    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
    inappropriate suggestions, which then have to be (patiently) rejected.

    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
    Steve Holden, Jul 14, 2006
    #6
  7. On 2006-07-05, <> 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
    Antoon Pardon, Jul 14, 2006
    #7
  8. Antoon Pardon <> wrote:

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

    > 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. Second:
    you overload the meaning of slicing and the slice operator and so on.
    range is perfectly integrated and the right tool for the job. There's no
    need to introduce new syntax to iterate over a range of integers.

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

    --
    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, Jul 14, 2006
    #8
  9. Guest

    Steve Holden:
    > 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
    > inappropriate suggestions, which then have to be (patiently) rejected.


    This attitude may have some downsides. The Python developers don't know
    everything, other people can have some experience of computer languages
    too. So people coming from different languages, like Erlang, Ruby,
    Dylan, Io, CommonLisp, C#, Haskell, and Lua can give useful suggestions
    to update and 'improve' Python. Often their suggestions can be unfit
    for Python, but if you don't waste a little of time evaluating their
    ideas, you lose some possibilities. Python 3.0 isn't just an occasion
    to remove some rust and obsolete things from Python, but a way to
    invent and adopt different ideas too. So I think wasting some time in
    that way is positive for Py 3.0 devs.

    Bye,
    bearophile
    , Jul 14, 2006
    #9
  10. {} for set notation

    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 A keyset of a dictionary should be
    viewed as a set not a list because it is a key_set_ after all. Also
    sets should get back their traditional notation of '{' and '}', which
    dictionaries have been in 'borrowing' for all this time in Python.

    When defining a non-empty set it could be unambiguous to share the
    notation. So :
    {1,2,3} is set([1,2,3])
    while
    {1:'a', 2:'b', 3:'c'} could still be the a dictionary. Of course then
    {1, 2, 3:'b'} would be undefined and would raise an exception or
    alternatively be equivalent to {1:None, 2:None, 3:'b'} - a dictionary.

    As far as the set and dictionary notation being "confusing" it seems
    that a common notation is actually a _benefit_, after all sets and
    dictionaries are not that different! A dictionary is a mapping
    (surgective explicit function?) from a _set_ of keys to a set
    (actually a bad or multiset in Python) of values. At the same time a
    set can also be regarded as a degenerate dictionary as in {1:None,
    2:None, 3:None}. A similarity of notation does make sense to me.

    Of course the empty set is the problem since {} could be interpreted
    ambiguously as both a set or a dictionary. I think it makes sense to
    give the '{}' notation to the empty _set_ as this will make more sense
    as far as common sense goes. If the proposal is to have {x} be the a
    set([x]) then it only makes sense for {} be a set([]). This will break
    compatibility with old code and that is why it should be in Python 3000
    not in 2.x.x The empty dictionary is probably best represented as {:},
    it is actually more clear this way as it shows that there is a key and
    a value separated by ':' and in this case they are both missing so it
    is an empty dictionary.

    Also the frozenset, although not used as often, could still probably
    get its own notation too.
    For example:
    1. ({1,2,3}) - a symmetry with tuples, which are also immutable.
    The problem of a one element tuple i.e. (10,) not (10) will also be
    present here. So just as there is a need to use a comma to make
    (10,)=tuple([10]) one would have to use a comma to specify that a tuple
    is needed and not a a frozenset() but at the same time the ({1,2,3})
    could then never be reduced to {1,2,3}.
    In other words:
    ({1,2,3},) is tuple({1,2,3})
    ({1,2,3}) is a frozenset([1,2,3]) and never just {1,2,3}.
    This notation would make the parser go 'nuts'. I think the next idea
    might be better:

    2. _{1,2,3}_ - the underscores '_' intuitively could mean that the
    braces are fixed blocks and will not "move" to accomodate addition or
    removal of elements i.e. the fact that the frozenset is immutable. Or
    perhaps a more verbose _{_1,2,3_}_ would be better, not sure...

    3. {|1,2,3|} or maybe |{1,2,3}| - same aesthetic rationale as above,
    '|'s look like 'fences' that will not allow the braces to 'move', but
    this would look to much like Ruby's blocks so 1 and 2 might be better.

    In general a 'set' are a fundamental data structure. It has always been
    secondary in traditional programming languages. For simplicity in
    implementation arrays and lists have been used to mimic a set. Now
    that Python has a built in set it only makes sense to give it its own
    notation and maybe Python 3000 is just the right time for it.

    - Nick Vatamaniuc

    wrote:
    > >From this interesting blog entry by Lawrence Oluyede:

    > http://www.oluyede.org/blog/2006/07/05/europython-day-2/
    > and the Py3.0 PEPs, I think the people working on Py3.0 are doing a
    > good job, I am not expert enough (so I don't post this on the Py3.0
    > mailing list), but I agree with most of the things they are agreeing
    > to. Few notes:
    >
    > - input() vanishes and raw_input() becomes sys.stdin.readline(). I
    > think a child that is learning to program with Python can enjoy
    > something simpler: input() meaning what raw_input() means today.
    >
    >
    > - dict.keys() and items() returns a set view
    >
    > This is being discussed here too a lot, I agree that they will just
    > become equivalent to iterkeys() and iteritems().
    >
    >
    > - dict.values() a bag (multiset) view
    >
    > I think this isn't a good idea, I think bags can be useful but in this
    > situation they make things too much complex.
    >
    >
    > http://www.python.org/dev/peps/pep-3100/#core-language :
    > - Set literals and comprehensions: {x} means set([x]); {x, y} means
    > set([x, y]). {F(x) for x in S if P(x)} means set(F(x) for x in S if
    > P(x)). NB. {range(x)} means set([range(x)]), NOT set(range(x)). There's
    > no literal for an empty set; use set() (or {1}&{2} :). There's no
    > frozenset literal; they are too rarely needed.
    >
    > I like the idea of set literals, but using {1:2} for dicts and {1, 2}
    > for sets may look a bit confusing.
    > And using {} for the empty dict is confusing even more, newbies will
    > use it a lot for empty sets. Maybe the {:} for the empty dict and {}
    > for the empty set are a bit better.
    > Maybe a better syntax can be use a different denotator, to distinguis
    > the two structures better. Some possibilities are nice looking but not
    > easy to type:
    > «1, 2»
    > Other may be confused with bitwise operators:
    > |1, 2|
    > Others are bad looking and not easy to type (some nationalized
    > keyboards don't have the `):
    > §1, 2§
    > `1, 2`
    > Some of them are too much long:
    > <<<1, ,2>>>
    > Maybe using two nested like this is better (you can't put a dict or set
    > in a set, so there are no ambiguities):
    > {{1, 2}}
    >
    > I don't have a definitive good solution, but I think that adopting a
    > bad solution is worse than using set(...). Set literals are cute but
    > not necessary. Choosing things that increase the probability of bugs
    > isn't good.
    >
    > ---------------------
    >
    > In the past I have suggested other possibilities for Py3.0, nothing
    > really important, but few things can be interesting.
    >
    > - cmp() (or comp(), comp4(), etc) returns 4 values (<, ==, >, not
    > comparable).
    > - do - while.
    > - NOT OR AND XOR as bitwise operators syntax.
    > - Better syntax for octals and hex numbers.
    > - obj.copy() and obj.deepcopy() methods for all objects.
    > - Simplification and unification of string formatting (I have seen they
    > are working on this already).
    > - Intersection and subtraction among dicts.
    >
    > Less important things:
    > - More human syntax for REs
    > - Optional auto stripping of newlines during an iteration on a file.
    > - String split that accepts a sequence of separators too.
    > - a function in the math library to test for approximate FP equality.
    > - something in cmath to do a better conversion of polar<->cartesian
    > complex number conversion
    > - xpermutations and xcombinations generators in the standard library.
    >
    > Bye,
    > bearophile
    Nick Vatamaniuc, Jul 14, 2006
    #10
  11. > 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
    > inappropriate 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.

    -Nick V.

    Steve Holden wrote:
    > 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.
    > >

    > 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
    > inappropriate suggestions, which then have to be (patiently) rejected.
    >
    > 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
    Nick Vatamaniuc, Jul 14, 2006
    #11
  12. tac-tics Guest

    Re: {} for set notation

    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? It is similar to how queue and stack are not in the
    default namespace. 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. I beleive the same applies in regards to sets.
    tac-tics, Jul 14, 2006
    #12
  13. 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.

    </F>
    Fredrik Lundh, Jul 14, 2006
    #13
  14. On Fri, 14 Jul 2006 18:45:07 +0200,
    Fredrik Lundh <> wrote:
    > 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
    A.M. Kuchling, Jul 14, 2006
    #14
  15. On 2006-07-14, Lawrence Oluyede <> wrote:
    > Antoon Pardon <> wrote:
    >
    >> 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
    Antoon Pardon, Jul 14, 2006
    #15
  16. Re: {} for set notation

    tic-tacs,

    But how often does one use a list or a tuple when a set is actually
    more meaningful? -- Probably more than expected, because traditionally
    comming from C and in the older Python versions there were no sets.

    A prime example are the keys of the dictionary. They are a _set_ not a
    list. If a list is returned by the keys() method, one might assume that
    somehow there is a special order to the keys.

    Or, for example, the other day I looked at some of my old code at some
    point I was gathering values for removal and I was using a list then I
    was doing "if deleteme is not in removelist:
    removelist.append(deleteme)". And I remember doing that more than one
    time. Looking back I would have used sets a lot more often especially
    if they had a quick easy notation like {1,2,3}.

    Another example is typical constant-like parameters. Again coming from
    Java and C we have been using FLAG1=1, FLAG2=1<<1, FLAG3=1<<2 then
    setting FLAG=FLAG1|FLAG2. This uses the bit arithmetics along with the
    bitwise 'or' operator. It is fine for C but in Python it looks odd.
    What we really want to say is that FLAG={FLAG1, FLAG2, FLAG3}. A new
    user would be puzzled by FLAG2=1<<1 or how come FLAG2=2 and FLAG3=4?.

    In general a set is a fundamental datatype. It was fundamental enough
    to include in Python as a builtin. Even though there was already the
    dictionary the list and the tuple. For completeness I think a set
    deserves its own notation. Once it has it, you'd be surprised how many
    people would more likely to use than if they had to type set([...]).


    Regards,
    Nick Vatamaniuc

    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? It is similar to how queue and stack are not in the
    > default namespace. 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. I beleive the same applies in regards to sets.
    Nick Vatamaniuc, Jul 14, 2006
    #16
  17. Antoon Pardon <> wrote:

    > 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_object) 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, Jul 14, 2006
    #17
  18. A.M. Kuchling <> wrote:

    > 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
    Lawrence Oluyede, Jul 14, 2006
    #18
  19. 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 <> wrote:
    > > 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, Jul 14, 2006
    #19
  20. 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 <> wrote:
    > > Antoon Pardon <> wrote:
    > >
    > >> 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
    Nick Vatamaniuc, Jul 14, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Hatcliff
    Replies:
    0
    Views:
    388
    John Hatcliff
    Aug 23, 2005
  2. Armin Rigo

    EuroPython 2006: Call for papers

    Armin Rigo, Apr 25, 2006, in forum: Python
    Replies:
    0
    Views:
    303
    Armin Rigo
    Apr 25, 2006
  3. Harald Armin  Massa

    Europython 2006 call for proposals

    Harald Armin Massa, May 18, 2006, in forum: Python
    Replies:
    0
    Views:
    249
    Harald Armin Massa
    May 18, 2006
  4. Samuele Pedroni
    Replies:
    0
    Views:
    282
    Samuele Pedroni
    May 18, 2006
  5. Michael Ivey
    Replies:
    13
    Views:
    173
    Dr Nic
    Sep 1, 2006
Loading...

Share This Page