Velocity Reviews > RE: Assignment to slice

# RE: Assignment to slice

Rich Krauter
Guest
Posts: n/a

 01-21-2004
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.

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

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Josiah Carlson
Guest
Posts: n/a

 01-21-2004
> 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

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

- Josiah

Terry Reedy
Guest
Posts: n/a

 01-21-2004

"Rich Krauter" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

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

Rich Krauter
Guest
Posts: n/a

 01-21-2004
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
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
>
> 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
Guest
Posts: n/a

 01-22-2004

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
> >
> > 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
Guest
Posts: n/a

 01-22-2004
> >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

sambo
Guest
Posts: n/a

 01-23-2004

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

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Daku VHDL 0 11-18-2009 04:54 PM Andrew Python 2 09-21-2008 02:23 AM Jens Lippmann Python 4 05-25-2004 08:56 PM James Henderson Python 2 01-22-2004 10:35 AM Rich Krauter Python 0 01-21-2004 05:01 PM