You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
self is the standard keyword for self-reference in Python OO. I suggest that we link it to special.
I tried to find prior discussion about this since I felt that this kinda had to be discussed before, but I found nothing. Apologies if that was the case!
Well, it was discussed a little bit before in #10.
I don't want to add highlighting for self for a number of reasons:
I actually tried it and I don't really like how it looks. It adds too many colors to the code to the point that it's getting harder to follow.
As @lonetwin already mentioned, self is actually just a conventional name for the first argument of a method. And if somebody uses for example just s instead it won't be highlighted and just will be confusing.
As it just an argument of a method it also can raise a question "why the other arguments not highlighted?" and also can add to the confusion.
It is a conventional name, but it is used in literally 99.99% of all OO Python code. I have worked with Python almost exclusively for the better part of a decade, and I have never seen anyone use anything but self. So, if someone averts themselves from this de facto standard, I don't think they will be confused if their tooling would not follow suit 100%. Even if they are, I would argue that the other 99.99% of all users would be happy to have all their keywords highlighted.
For your first and second points, they can be tweaked. self highlight could be a default-on option so that it can be disabled, and adding highlights for other arguments is actually something that can be done. I have already implemented a light way (highlighting *args and **kwargs and the value part of key=value) into this project, but I was holding off on making PRs until this was resolved. Guess I won't be adding them.
I'll respect your decision, but I'll also express some general concern about the Open Source way of disregarding useful ideas and changes because they might be troublesome for a single hypothetical power user. The lack of colored prompts and tab completion in default Debian and Ubuntu shells come to mind; the argument was that people still using print terminals or really slow computers would have a slightly worse time.
I'll respect your decision, but I'll also express some general concern about the Open Source way of disregarding useful ideas and changes because they might be troublesome for a single hypothetical power user.
I think the main point of Open Source is that you can create your own version of a project if you think that your changes are useful and they can't be incorporated to the mainline version for some reason. It's actually one of the reasons why this project exists.
Activity
lonetwin commentedon Dec 17, 2014
Strictly speaking
selfis not really a keyword but yeah it would be good to highlight it (and the other strong conventional keywordclsas well)hdima commentedon Dec 28, 2014
Well, it was discussed a little bit before in #10.
I don't want to add highlighting for
selffor a number of reasons:selfis actually just a conventional name for the first argument of a method. And if somebody uses for example justsinstead it won't be highlighted and just will be confusing.Olivia5k commentedon Dec 29, 2014
It is a conventional name, but it is used in literally 99.99% of all OO Python code. I have worked with Python almost exclusively for the better part of a decade, and I have never seen anyone use anything but
self. So, if someone averts themselves from this de facto standard, I don't think they will be confused if their tooling would not follow suit 100%. Even if they are, I would argue that the other 99.99% of all users would be happy to have all their keywords highlighted.For your first and second points, they can be tweaked.
selfhighlight could be a default-on option so that it can be disabled, and adding highlights for other arguments is actually something that can be done. I have already implemented a light way (highlighting*argsand**kwargsand the value part ofkey=value) into this project, but I was holding off on making PRs until this was resolved. Guess I won't be adding them.I'll respect your decision, but I'll also express some general concern about the Open Source way of disregarding useful ideas and changes because they might be troublesome for a single hypothetical power user. The lack of colored prompts and tab completion in default Debian and Ubuntu shells come to mind; the argument was that people still using print terminals or really slow computers would have a slightly worse time.
hdima commentedon Jan 2, 2015
Probably not so good example but there's a class which uses
sinstead ofself: https://hg.python.org/cpython/file/3.4/Lib/sched.py#l45I think the main point of Open Source is that you can create your own version of a project if you think that your changes are useful and they can't be incorporated to the mainline version for some reason. It's actually one of the reasons why this project exists.
syntax: Implement raw format strings