Hi, I think that the main point of disagreement between Georg (and possibly others) and me is summed up by the expectation of what a[M:N] behaves like.
I imagine the most common use of a[M:N] to be like get(dict, key) where the programmer is already well aware that the key might not exist in the dict. In all the times where I have used a[M:N] I have never actually assumed that (M,N < len(a)). I always use it in the loose sense "give me any elements between indices M and N if there are any". On the other hand, Georg seems to want to use a[M:N] just like a[M]. In this case, the programmer is actually assuming that the array is at least (M+1) long and therefore it is rightly an error to signal it as such. I think it becomes a matter of deciding which approach to list slicing makes more sense. If Bram thinks that Georg's approach makes more sense, I shall argue no more. I do hope however that the behavior of a[M:N] is dictated by more thought that just likening to a[M] without any thought given to its most common use. Thanks, Srinath On 4/22/06, Srinath Avadhanula <[EMAIL PROTECTED]> wrote: > Hi, > > On 4/22/06, Georg Dahn <[EMAIL PROTECTED]> wrote: > > In my opinion one has done something wrong if one wants to get a sublist > > whith wrong bounds. That's why an error has to be produced. Returning an > > empty list looks like everything is ok where it is not. It takes some > > time to find an error if no error message is produced in such cases. > > Why is this "wrong"? And wrong is very subjective... I can agree that > getting a non empty slice where none exists is "wrong". Why is mereley > querying for out-of-bounds "wrong"? By your logic, the get() function > for dictionary objects is "wrong". The programmer should be forced to > write an if statement every time he could have done the same thing with > get(). A lot of time, there is an expectation of default values... > > Besides, as I elaborated in my previous email (and which you didn't > address) is that returning an empty list is at least from a mathematical > perspective correct. Your statement "returning an empty list looks like > everything is ok" is also completely subjective. As a programmer I know > that getting an empty list implies that my range is out of bounds. Why > should the language get in the way with statements like "you are > definitely doing something wrong". > > > > The most common use-case for the slice operation I can think of is: > > > > > > for item in somelist[M:N] > > > " do something > > > endfor > > > > This is a good example. M and N are not further described here. But M > > and N must come from somewhere. If they are out of bounds, then in many > > or even most cases the programmer has done something wrong. Even if > > Why?! Why is this "wrong"? Suppose I have a function which asks the user > for a long list and then wants to use not more than the first three > elements. Or for that matter, maybe the first argument needs to be > discarded or used differently... I can easily imagine many cases like > this, where producing an error is needless intrusion and produces more > complicated looking code where the intent was actually simple. > > A real world example is in vim-latex, where the user is expected to > create a setting Tex_HotKeyEnvironments. This is a list of environments > which needs to be mapped to the function keys. Since only the first > 4 function keys should be mapped, I would have done something like: > > for item in Tex_HotKeyEnvironments[:3] > " do something > endfor > > Is it an "error" for the user to specify a list less than 4 long? > I think not! > > > there may be some cases where this could make sense, it will be better > > to add an if. An error is no intrusion as you call it, but a very > > helpful signal that there is something wrong. > > Once again, in many cases, the list not containing elements given in the > range is not an error but an expected use-case. It is in these cases > where producing an error is annoying. You can always use "if len(list)" > statements where you actually care about the lenght of the list. > > > > Having a[M:N] never be an error makes the above work flawlessly. > > > > What does 'flawlessly' mean here? Not to get an error is not good if > > there is one. What may result in more harm: an additional if or writing > > a good code, where your examples doesn't exist, or not producing an > > I do not thinking that stuffing code with needless if statements makes > "good code". > > > But somewhere you have assigned some values to M and N. That will be > > done dynamically, too. If they are out of bounds, a highly probable > > reason for that is, that you have done something wrong. > > > In many many cases, there is no fault in logic. I fully expect that the > list might be shorter and the > > for item in list[M:N] > " do something > endif > > automatically handles this since the loop is never entered if the range > is out of bounds. > > > But these languages have in common, that it is very hard to find some > > types of errors, which can be avoided in more restricting languages. > > I personally feel that Python is one of the best languages around as far > as language design goes. There are usually extremely good reasons why > things are done the way they are. In this case, I happen to completely > agree with it. In all the cases where I have used lists, the if > statement will be completely redundant. I am asking for this due to > real-word use-cases, not due to some abstract feeling of "right" or > "wrong". > > Best wishes, > Srinath >
