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

David L Neil PyTutor at DancesWithMice.info
Tue Nov 12 15:28:29 EST 2019


On 12/11/19 10:39 PM, Alan Gauld via Tutor wrote:
> On 12/11/2019 07:15, DL Neil via Tutor wrote:
> 
>>>>    >>    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.
> 
> Hasn't this been a feature of vi since its origins - possibly even a
> feature of ex, before vi even existed? You just run a grep command
> then step through the results visiting each line in turn. Or am I
> missing something?

No, not missing anything, per-se.

I guess it depends upon how one sees 'the world'. The *nix tradition has 
been one of small tools, doing one job, and doing it well; and being 
able to pipe/chain them. However, that world is changing, eg the 
standardisation/uniformity, efficiency vs tradition etc argument that 
erupted when systemd arrived in Linux. "One...to rule them all".

So, yes, it is possible to use vi for editing, grep for searching, 
python3 for interpreting, pytest for unit testing, etc, etc - under 'the 
best tool for the job' heading; whereas a GUI editor (with add-ons, per 
the OPs discussion) brings it all 'under one roof' or 'at the click of a 
mouse', eg "File | Save" might mean: save, then lint, then pytest.

In the case of SublimeText (mentioned only because it is what I am 
currently using), a bulk-search causes a new editing tab to be opened 
and the results to be 'displayed' there, They can then be used for 
'editing'; the ones I don't deal with 'now' can be thrown on a ToDo 
list, etc, etc - all from the comfort of my arm-chair (assuming I'm 
sitting there whilst editing).)

 From the constructivist theories of cognition, the GUI makes it easy 
for a beginner (or a 'forgetterer'!) to 'explore' and find/learn such 
powerful facilities for him-/her-self - 'there must be a better way; 
where is it?'. Whereas the *nix approach requires/d a very much 
less-obvious learning-path.

[I haven't gone back to check, but compare/imagine explaining those two 
within the pages of a book! Which would you prefer? Which would enjoy 
the greatest likelihood of trainee-success/mastery?]

Traditionally, a *nix/vi/emacs enthusiast would argue that (s)he can do 
things faster - in part by never lifting hands from keyboard (cf the GUI 
!usually being mouse-driven). However, in this (wider search) example, I 
doubt that claim would stand.

NB I'm not saying one 'way' is completely correct and thus the other the 
epitome of evil. Per earlier comment: "horses for courses". [IMHO] 
you/yous should use (hah!) whichever tool 'works' for you. There are two 
riders (pun my word!): (i) that you be 'aware' of other opportunities 
(eg new products, developments to 'competitive products') and thus take 
advantage of productivity improvements as they become possible; and (ii) 
that what you do has a 'social fit' with the other members of your team.
-- 
Regards =dn


More information about the Tutor mailing list