Re: exists(*Foo!garbage) = 1 ?
Hi Bram,
On 4/29/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
This happens not just for functions, but variables etc. also. For
variables, I can work around this by using has_key(g:, varname)
instead of exists('g:'.varname).
Right, extra text after the function name was ignored. It's easy to
change, see the patch below.
Thanks for the patch.
Would there be scripts that depended on the text being ignored? Hmm, if
someone has been using exists('function()') then that worked, but won't
work after the patch.
I think I better not change this just before a release.
I would think that a major release of vim is a good time to fix such
things which are possibly not backwards compatible, since most users are
expecting significant changes anyways. Also I never saw that you could
use exists('function()') anywhere in the docs (it always returns 0 when
I try). Its supposed to be exists('*function'), right? Why accomodate
undocumented behavior, when there is a good documented alternative?
I am afraid that if this gets into vim7 release, then this behavior will
be promoted to a feature...
Thanks,
Srinath
exists(*Foo!garbage) = 1 ?
Hi,
If there is a function called Foo(), then it looks like exists('*Foo\W.*')
evaluates to 1. For example
:fun Foo
: return 1
:endfun
:echo exists('*Foo!asdf')
prints 1
This happens not just for functions, but variables etc. also. For
variables, I can work around this by using has_key(g:, varname)
instead of exists('g:'.varname).
Thank you,
Srinath
Re: matchlist() behavior
Hi Bram,
On 4/24/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
At least the matching submatches should be returned. When some of the
last submatches don't match it would still be easy if you can access the
resulting list without having to check if the item is really there.
Thus matchlist() should always return a list with ten items. Submatches
that didn't match will then have an empty item.
Example: echo matchlist('acd', '\(a\)\?\(b\)\?\(c\)\?\(.*\)')
Results in: ['acd', 'a', '', 'c', 'd', '', '', '', '', '']
Yes... This is (almost) exactly what I wanted. I guess making it not
have the restriction that only 10 groups are allowed would be perfect.
I just checked that the biggest RE I have personally ever used has
7 groups... So I guess I will not have any problems even with the
restriction.
Thanks,
Srinath
Re: a[M:N]
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
Re: a[M:N]
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
