[Tutor] What editor tools (plugins/extensions) would you consider essential for efficient Python development?

[DL Neil]

On 12/11/19 4:33 PM, boB Stepp wrote:
> On Mon, Nov 11, 2019 at 8:17 PM DL Neil via Tutor <tutor at python.org> wrote:
> I _did_ ask about Visual Studio Code editor in a _separate_ thread,
> but after trying out its Vim extension I decided to stick with what I
> have been using Vim/Neovim.  And I only asked about VSC because of an
> article that popped up on my phone's news feed that suggested VSC is
> the most popular editor currently and that piqued my interest.

On the basis of earlier comments, that's it then; but...


>> On 12/11/19 1:53 PM, boB Stepp wrote:
>>> On Fri, Nov 8, 2019 at 9:54 PM boB Stepp <robertvstepp at gmail.com> wrote:
>>>> What Neovim plugins would any of you recommend as especially useful?

>>    4) Code autoformatting;
>> ? doesn't the (Python) editor do this
> 
> If we are speaking of the same thing, no.  I am talking about tools
> like Black, yapf and autopep8, which actually edit/rearrange your code
> to make it conform to the selected coding style, usually PEP 8, but I
> found optionally yapf does a Facebook and Google style.

We probably are not. However, within your list aren't there two sides of 
the same/similar coins? Some wait for us to type and then 'correct' the 
formatting; others are more up-front.

So, my expectation is that having typed a colon, eg for...: the 
following Enter key will be augmented with an appropriate indentation 
'into' the loop. Most modern/GUI editors seem to do this 'out of the box'.


>> 5) Implementing type annotation and its checking
>> +1 although I see mypy as operating at the same time as/effectively a
>> single unit with pytest (which I saw a 'missing' from your previous
>> list; despite my using just such a plug-in 'all the time')
> 
> I want to eventually switch to pytest, but I first want to master the
> standard library unittest module.  For instance at work I will never
> have access to pytest because of their software installation
> prohibitions on our planning software platform.  And I don't think I
> will lose anything as the pytest docs says it will happily run
> unittest tests.

I believe so, but have not tested such a claim. Similarly, I may recall, 
but can't say if there are similar for the automatic save-and-test of 
other testing regimes, eg unittest, mocks...



>>   >>      4)  File explorer plugins.
>> ? to do what
> 
> Apparently to have a "nicer" file system interface than what the
> editor natively supplies.

ST has a panel with both a list of the open files and a tree of the 
project's directory/ies. This is displayed optionally.


>>   >>      5)  Bracket and quote completion plugins.
>> +1 but surely part of the editor
> 
> AFAIK, Vim/Neovim only natively highlights matching brackets, but will
> not complete them for you.  However, there are at least a couple of
> plugins that will provide that functionality.

Again, seems fairly standard out-of-the-box, amongst the modern crop.


>>   >>      6)  Comments plugins.
>> ? which do what
> Apparently allow for some sort of shortcut to insert comments or
> convert non-commented lines into comments.

Ah, yes. Alt+E, M - whatever that is called in English. BTW the 
definition of "comment" varies by language, eg # or //. Which now makes 
me wonder if there are 'language' plug-ins or if the range that I use 
came as-standard.


>>   >>      9)  Multiple cursor plugins.
>> +1 I find this very handy, from time-to-time (it's built-in to ST's editor)
> I had checked out ST a few years ago and at that time this was one of
> their oft-touted selling points.  I played around with it a little
> then, but my coding sophistication did not match the editor's
> sophistication.

I didn't cover this earlier - without reference to personal abilities or 
skill-levels, but it is most relevant.

It is a topic us-trainers often spend ages debating - and my earlier 
comment about the "cognitive load" of learning the editor IN ADDITION to 
your primary learning-objective - in this case, learning Python. I've 
been 'pushing' the idea of using an 'intro editor' at the beginning, to 
ease 'entry' (in the case of Python, on this list we have strong 
representation for Idle, but there are others - and if it were my 
training language I'd be pushing for an editor which shows the 
allocation of storage). However, the main argument-against, is that 
professionals are more likely to use a 'professional tool'. So, 
somewhere between 'beginner' and 'advanced' training, there's an extra 
task/aim - learning SublimeText, PyCharm, VScodium, or whatever. Who 
likes 'extra work'?

So, the choice of editor (plus add-ons) should indeed be matched to the 
skills of the individual.


>>   >>    11)  "Fuzzy" searching plugins.
>> ? which do what
> 
> Apparently you type _something_ into the search area and it will look
> for _something_ in a variety of places:  file names, contents of
> files, contents of your open buffers, etc.

Ah yes, when I first discovered this, I was SO pleased! The ability to 
search within all open files, within all the files of a project was 
revolutionary over the original 'within a single file' limitation.


>> Your other comment is worthy of consideration: all these things take
>> time to learn and then commit to muscle-memory/to become habits.
>> Meantime, your Python dev work is slowed/brain-power is being absorbed
>> off-task.
>>
>> I have colleagues who trade editors, sorry, maybe that should be IDEs,
>> about as often as they change their under-wear. That comment about it
>> taking time to come-up-to-speed seems to convince them that I am mad
>> (quite possible - you don't have to be to work here - but it helps!). At
>> least I can type faster than they, suffer less from FoMo, and am
>> waaaaaay better-looking)
> 
> Maybe this is a function of youth?  My son, a teenager now, said to me
> something like, "Papa, just try Visual Studio Code and see how you
> like.  If you don't like it, either try something else or go back to
> what you had been using.  It's no big deal!"

Perhaps this is more than valid. How else will we realise 'progress', 
and stay up-to-date? However, a quick look to stay 'aware', has little 
in common with the motives and costs of editor-hoppers.

At the risk of pouring fuel on the 'fire', I have to say that GUI 
editors (with keyboard short-cut keys) offer (me) an easier and equally 
powerful option (which may say more about my level of skill - per 
above). I'll maintain a basic skill in vi for server config maintenance 
and similar; but if I'm spending all day creating, I'd rather use an 
easy-to-view GUI tool.

There are people who can make vi/emacs stand-up and beg (I'm not one of 
them) and more power to their right arm. However, there are others who 
would have to stay in the nursery unless they use a WYSIWYG tool.
-- 
Regards =dn