RE: Assignment to slice

Discussion in 'Python' started by Rich Krauter, Jan 21, 2004.

  1. Rich Krauter

    Rich Krauter Guest

    I hope this gets tacked on to the original thread.
    Sorry if it doesn't.

    I see your point. However I could be wrong, but I
    don't know if what you say is really the case, since
    negative indexes are just shorthand for

    actual positive index = i + len(x),

    where i is the negative index, and len(x) >= abs(i).

    e.g.

    x = [1,2,3,4,5]
    x[-4] is equivalent to x[-4+len(x)], which is x[1]
    x[-4:-2] is equivalent to x[(-4+len(x)):(-2+len(x))],
    which is x[1:3]

    I contend that my restriction may still hold even in
    the case of negative indices, since negative indices
    (which are just convenient shorthand), should map to
    positive indices.

    In that case,
    x = [1,2,3]
    x[-10:-9] = [54] should return an exception too since,

    x[-10:-9] = x[-10+len(x):-9+len(x)] == x[-7:-6], which
    is REALLY out of bounds of x.

    Instead python will just tack stuff on to the front of
    the array. Which, I still believe, is totally
    inconsistent. But what do I know? I have about 5
    minutes of python experience.

    I guess I just don't like that behaviour. At least in
    perl if I assign something to a list slice:

    @x[2..3] = (4,5);

    the list grows, so that the things I inserted are at
    the indices where I think I inserted them.
    That is, @x now contains (0,0,4,5).

    So later if I ask for $x[3], or $x[4], I get back what
    I put there in the first place.

    In python this is not true. The indices will change
    because of the append-like behavior:

    >> x = []
    >> x[2:3] = [4,5]
    >> x

    [4,5]

    That just doesn't seem right. Either always raise an
    out-of-bounds exception or always grow the list.
    Python seems to be doing a combination of both, and in
    an inconsistent way, at that (or, more accurately, in
    a way that does'nt make sense to me).

    Oh well. Maybe my problem is that I'm using perl as my
    model of consistency. Plus, it's a minor issue anyway.
    I just need to be aware of it, and not try to write
    perl code in python. I need to learn to write python
    code in python.

    Thanks for your input.

    Rich


    > This doesn't answer you fully but Python is at least
    > consistent in that
    > slicing - as opposed the indexing of your first case

    -
    > *never* raises an
    > IndexError. It's not unique to assignment. "print
    > x[1000:9000]" works too.>


    > The fact that slices can extend outside the current
    > range is useful.
    > Otherwise you couldn't use them to extend sequences.
    > Adding to the end
    > would still be possible with your proposed

    restriction >on first index., but
    > what if you wanted to add stuff to the *start* of

    the > list. Currently this
    > works:
    >


    > >>> x = [1, 2, 3]
    > >>> x[-10:-9] = [54]
    > >>> x

    > [54, 1, 2, 3]



    >
    > In this case to be consistent you must insist that

    the second index exist in
    > the array, i.e. insist on:


    > >>> x[-4:-3] = [54]


    > James
    > --
    > James Henderson, Logical Progression Ltd.
    > http://www.logicalprogression.net/
    > http://sourceforge.net/projects/mailmanager/


    > On Wednesday 21 January 2004 5:01 pm, Rich Krauter >

    wrote:
    > I do not understand why python behaves the way it

    does
    > in the following code:
    >
    > Here, Python doesn't like that I'm assigning
    > out-of-range. OK. That's fine.
    >
    > >>> x = []
    > >>> x[5] = 3

    >
    > Traceback (most recent call last):
    > File "<interactive input>", line 1, in ?
    > IndexError: list assignment index out of range
    >
    > However, the following seems very strange. Assigning
    > to a slice, over non-existent array indexes, sets

    x[0]
    > and x[1].
    >
    > >>> x[2:5] = [3,4]
    > >>> x

    >
    > [3,4]
    >
    > >>> x[1000:9000] = [5]
    > >>> x

    >
    > [3, 4, 5]
    >
    > Why does assigning to a slice of non-existent array
    > elements fill in the array, starting with the first
    > empty array position? (Acts like [].append() or
    > [].extend()?)
    >
    > Why not raise an out-of-bounds exception here too?
    > Wouldn't that be more consistent with the first

    case,
    > in which I tried to assign out-of-range, and got an
    > exception?
    >
    > IMO, at least the first index in the slice should be
    > required to exist in the array. If not, raise an
    > exception. That way, assigning to the slice fills in
    > the array in a predicatable way without having to do
    > len() checks first to ensure that you know where in
    > the array the slice is actually going to be

    inserted.
    >
    > But I'm sure it is the way it is for a good reason.
    > Hopefully someone can clue me in.
    >
    > Thank you in advance.
    >
    > Rich



    __________________________________
    Do you Yahoo!?
    Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
    http://hotjobs.sweepstakes.yahoo.com/signingbonus
     
    Rich Krauter, Jan 21, 2004
    #1
    1. Advertising

  2. > Instead python will just tack stuff on to the front of
    > the array. Which, I still believe, is totally
    > inconsistent. But what do I know? I have about 5
    > minutes of python experience.


    > Oh well. Maybe my problem is that I'm using perl as my
    > model of consistency. Plus, it's a minor issue anyway.
    > I just need to be aware of it, and not try to write
    > perl code in python. I need to learn to write python
    > code in python.


    There are a few choices that one can make when allowing slice reading
    and writing in sequences. Python made one: never cause an exception for
    integer arguments, and certain indices map to the same location. Perl
    made another: extend the sequence if necessary to fill it out.

    Both are consistant and predictable. Python does it one way, Perl does
    it another. Heck, Python has variable definitions that are done one way,
    Perl has variable definitions that are done another. They were choices
    made during the creation that fit a paradigm.

    Expecting Python to behave like Perl is like expecting your mother to
    pee standing up; without alteration, it's not gonna happen.

    - Josiah
     
    Josiah Carlson, Jan 21, 2004
    #2
    1. Advertising

  3. Rich Krauter

    Terry Reedy Guest

    "Rich Krauter" <> wrote in message
    news:...

    Guido very intentionally made index access of items strict and slice access
    of subsequences permissive. This partly due to the difference between
    items, which must exist, and subsequences, which can be empty. It also
    gives programmers a choice in some situations. For instance, seq[0] only
    works on non-empty seqs while seq[0:1] gives you a sequence with 0 or 1
    items without raising an error to catch when there are 0.

    > Oh well. Maybe my problem is that I'm using perl as my
    > model of consistency.


    How amusing ;-)

    > I just need to be aware of it, and not try to write
    > perl code in python. I need to learn to write python
    > code in python.


    Definitely. Good insight.

    Terry J. Reedy
     
    Terry Reedy, Jan 21, 2004
    #3
  4. Rich Krauter

    Rich Krauter Guest

    I'm just surprised that nobody thinks it's unusual.

    >>> x = []
    >>> x[4] = 5

    Python says "Wrong! Can't do that! I'm quitting now!"
    >>> x = []
    >>> x[4:5] = [1,2,3,4,5]

    Python says "Ok. Cool. Those indices don't exist in x so I'll just stick
    your list at the beginning,
    and the indices you used in the slice have nothing to do with where the
    elements end up,
    since they don't exist in the list anyway."

    To me that doesn't look much different than if python were to do this:
    (not real code obviously)
    <fiction>
    >>> x = []
    >>> x[4] = 5
    >>> x

    [5]
    Python says "Well, x[4] doesn't exist so you must have meant x[0]."
    <fiction>

    That would make no sense. So why does it make sense to do that same
    exact thing if you're
    assigning to a slice, instead of an element?

    That's what I see as inconsistent; not that python does not behave just
    like perl. I'm sure that
    a little more time will reveal this 'inconsistency' as a shortcoming in
    the wiring of my brain, and
    not a weird python idiosyncrasy. It's cool to hear other people's take
    on it.
    Thanks alot.
    Rich







    On Wed, 2004-01-21 at 16:09, Josiah Carlson wrote:

    > > Instead python will just tack stuff on to the front of
    > > the array. Which, I still believe, is totally
    > > inconsistent. But what do I know? I have about 5
    > > minutes of python experience.

    >
    > > Oh well. Maybe my problem is that I'm using perl as my
    > > model of consistency. Plus, it's a minor issue anyway.
    > > I just need to be aware of it, and not try to write
    > > perl code in python. I need to learn to write python
    > > code in python.

    >
    > There are a few choices that one can make when allowing slice reading
    > and writing in sequences. Python made one: never cause an exception for
    > integer arguments, and certain indices map to the same location. Perl
    > made another: extend the sequence if necessary to fill it out.
    >
    > Both are consistent and predictable. Python does it one way, Perl does
    > it another. Heck, Python has variable definitions that are done one way,
    > Perl has variable definitions that are done another. They were choices
    > made during the creation that fit a paradigm.
    >
    > Expecting Python to behave like Perl is like expecting your mother to
    > pee standing up; without alteration, it's not gonna happen.
    >
    > - Josiah
     
    Rich Krauter, Jan 21, 2004
    #4
  5. All 'different' language features are 'unusual' until people get used to
    them. While you are currently saying, "I can't believe people don't
    think this is strange", the rest of us got over it, and may even be
    using the feature to get the job done.

    Hell, I think that Perl variables are f-ing weird. In the dozen
    languages I've learned over the years, Perl is the only one where you
    have to say hey, you this variable I'm accessing now, it is a scalar,
    not a string. What the hell is that? On the other hand, Perl users
    have gotten used to it, and don't think it is strange.

    The real difference is that I'm not hanging out on Perl newsgroups or
    mailing lists saying, "Dude, this variable thing is wack" (this actually
    has more to do with the fact that I don't much like Perl, and don't use
    it, than anything else). Get used to slices working the way they do, it
    is not likely to change anytime soon.

    - Josiah


    > I'm just surprised that nobody thinks it's unusual.
    >
    > >>> x = []
    > >>> x[4] = 5

    > Python says "Wrong! Can't do that! I'm quitting now!"
    > >>> x = []
    > >>> x[4:5] = [1,2,3,4,5]

    > Python says "Ok. Cool. Those indices don't exist in x so I'll just stick
    > your list at the beginning,
    > and the indices you used in the slice have nothing to do with where the
    > elements end up,
    > since they don't exist in the list anyway."
    >
    > To me that doesn't look much different than if python were to do this:
    > (not real code obviously)
    > <fiction>
    > >>> x = []
    > >>> x[4] = 5
    > >>> x

    > [5]
    > Python says "Well, x[4] doesn't exist so you must have meant x[0]."
    > <fiction>
    >
    > That would make no sense. So why does it make sense to do that same
    > exact thing if you're
    > assigning to a slice, instead of an element?
    >
    > That's what I see as inconsistent; not that python does not behave just
    > like perl. I'm sure that
    > a little more time will reveal this 'inconsistency' as a shortcoming in
    > the wiring of my brain, and
    > not a weird python idiosyncrasy. It's cool to hear other people's take
    > on it.
    > Thanks alot.
    > Rich
    >
    >
    >
    >
    >
    >
    >
    > On Wed, 2004-01-21 at 16:09, Josiah Carlson wrote:
    >
    > > > Instead python will just tack stuff on to the front of
    > > > the array. Which, I still believe, is totally
    > > > inconsistent. But what do I know? I have about 5
    > > > minutes of python experience.

    > >
    > > > Oh well. Maybe my problem is that I'm using perl as my
    > > > model of consistency. Plus, it's a minor issue anyway.
    > > > I just need to be aware of it, and not try to write
    > > > perl code in python. I need to learn to write python
    > > > code in python.

    > >
    > > There are a few choices that one can make when allowing slice reading
    > > and writing in sequences. Python made one: never cause an exception for
    > > integer arguments, and certain indices map to the same location. Perl
    > > made another: extend the sequence if necessary to fill it out.
    > >
    > > Both are consistent and predictable. Python does it one way, Perl does
    > > it another. Heck, Python has variable definitions that are done one way,
    > > Perl has variable definitions that are done another. They were choices
    > > made during the creation that fit a paradigm.
    > >
    > > Expecting Python to behave like Perl is like expecting your mother to
    > > pee standing up; without alteration, it's not gonna happen.
    > >
    > > - Josiah
     
    Josiah Carlson, Jan 22, 2004
    #5
  6. > >Hell, I think that Perl variables are f-ing weird. In the dozen
    > >languages I've learned over the years, Perl is the only one where you
    > >have to say hey, you this variable I'm accessing now, it is a scalar,
    > >not a string. What the hell is that? On the other hand, Perl users
    > >have gotten used to it, and don't think it is strange.

    >
    > This seems to have emerged from a Perl tendency to
    > implement values as strings wherever possible. You're
    > saying "Use the stringness of this variable, rather than,
    > say, its intness." Weak typing, but it's what lets Perl
    > automatically fill in missing array values with some
    > assurance that it won't all go kaboom in the next statement.


    Mel,
    There are many ways to assure "that it won't go all kaboom in the next
    statement". Perl's choice is just that, a choice. Every language
    designer gets to make more than a few (close to semi-infinite) choices
    in how their language is going to work. The rest of us get on with our
    lives and use the language. Please let us get on with just writing code
    in whatever language we feel we need to, and stop talking about the
    different individual choices that every language designer made in the
    last 10 years.

    - Josiah
     
    Josiah Carlson, Jan 22, 2004
    #6
  7. Rich Krauter

    sambo Guest

    Rich Krauter wrote:

    > I'm just surprised that nobody thinks it's unusual.
    >
    > >>> x = []
    > >>> x[4] = 5

    > Python says "Wrong! Can't do that! I'm quitting now!"
    > >>> x = []
    > >>> x[4:5] = [1,2,3,4,5]

    > Python says "Ok. Cool. Those indices don't exist in x so I'll just
    > stick your list at the beginning,
    > and the indices you used in the slice have nothing to do with where
    > the elements end up,
    > since they don't exist in the list anyway."
    >
    > To me that doesn't look much different than if python were to do this:
    > (not real code obviously)
    > <fiction>
    > >>> x = []
    > >>> x[4] = 5
    > >>> x

    > [5]
    > Python says "Well, x[4] doesn't exist so you must have meant x[0]."
    > <fiction>
    >
    > That would make no sense. So why does it make sense to do that same
    > exact thing if you're
    > assigning to a slice, instead of an element?
    >
    > That's what I see as inconsistent; not that python does not behave
    > just like perl. I'm sure that
    > a little more time will reveal this 'inconsistency' as a shortcoming
    > in the wiring of my brain, and
    > not a weird python idiosyncrasy. It's cool to hear other people's take
    > on it.
    > Thanks alot.
    > Rich
    >
    >

    Well one might argue, I suppose, that the key word here is LIST - good
    for storing strings not so for numeric data/matrixes.

    Imagine my surprise when I was trying to find my numeric command line
    arguments with int()
    only to find int( "string" ) != 0 but an exception is raised instead.

    Cheers
     
    sambo, Jan 23, 2004
    #7
    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. Rich Krauter

    Assignment to slice

    Rich Krauter, Jan 21, 2004, in forum: Python
    Replies:
    0
    Views:
    354
    Rich Krauter
    Jan 21, 2004
  2. James Henderson

    Re: Assignment to slice

    James Henderson, Jan 21, 2004, in forum: Python
    Replies:
    2
    Views:
    287
    James Henderson
    Jan 22, 2004
  3. Jens Lippmann

    Slice assignment for strings?

    Jens Lippmann, May 25, 2004, in forum: Python
    Replies:
    4
    Views:
    462
    Paul Rubin
    May 25, 2004
  4. Andrew
    Replies:
    2
    Views:
    236
    Stephen Horne
    Sep 21, 2008
  5. Daku
    Replies:
    0
    Views:
    718
Loading...

Share This Page