Hi Carlos,

> On Aug 1, 2015, at 3:41 AM, Carlos Pita <[email protected]> wrote:
> 
> > OK. But there still remains the question of discrepancy between:
> >
> > class A:
> >     filter = None
> 
> Here filter is a variable locally scoped to the block defined by A, in that 
> sense this is not different from:
> 
No, it’s not a locally scoped variable (binding in Python).
It’s a class attribute.
> def a():
>     filter = None
> 
This is a locally scoped binding.
> Both clashes with the "auto-global" builtin.
> 
> Fortunately the most common case will be:
> 
> class A:
> 
>   def filter(...): ...
> 
> where filter would be highlighted because of the def anyway.
> 
I would still prefer to see this named member_filter, or any reasonable 
qualifier beside member, if I reviewed that code.
> > and:
> >
> > a = A()
> > a.filter = 2
> 
> Here a (and even A) is a potential offender but not filter, which is resolved 
> inside a.
> 
This is the same class attribute from above being assigned a value here.
Why would you have it highlighted above and not here?
> The rule is simple: an unqualified variable named like a builtin is 
> highlighted to signal potential mistakes / bad smell.
> 
> There already is a variable to control highlighting of builtins. Currently 
> it's a toggle but it could have 3 levels instead:
> 
> 0: never.
> 1: only unqualified.
> 2: always.
> 
> Heuristically I think 1 does a better job, but you can set the default to 2 
> if you prefer.
> 
I understand fully what you ask for. It’s still inconsistent for the case of 
class attributes.

I just wonder if there is really a value to complicate the highlighting code 
for a small use case like this compared to the value this “warning” gives. You 
do realize that this highlighting always existed and never bothered anybody 
until now. What if this gets changed and then users start complaining about the 
fact it’s not highlighted any more.

Let’s have others chime in and take a look at this next week.
I’m taking a break this weekend.

Zvezdan


-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui