PyDev adventures

Thursday, March 01, 2018

The major change in this release is that PyDev now recognizes that folders no longer require __init__.py files to be considered a package (PEP 420).

Although this is only available for Python 3.3 onwards, PyDev will now always display valid folders under the PYTHONPATH as if they were packages.

There were also some improvements, such as recognizing that dlls may have a postfix (so that dlls for multiple versions of Python may be available in the same folder) and a number of bugfixes (see: http://www.pydev.org has more details).

Besides those, a good amount of work in this release was refactoring the codebase so that PyDev could also be available as a language server for Python, to enable it to be used on Visual Studio Code (http://www.pydev.org/vscode), so, Visual Studio Code users can now also use many of the nice features on PyDev ;)

Monday, February 19, 2018

The first release already provides features such as code analysis, code completion, go to definition, symbols for the workspace and editor, code formatting, find references, quick fixes and more (see http://www.pydev.org/vscode/ for details).

All features have a strong focus on speed and have been shaped by the usage on PyDev over the last 14 years, so, I believe it's already pretty nice to use... there are still some big things to integrate (such as the PyDev debugger), but those should come on shortly.

The requisites are having java 8 (or higher) installed on the system (if it doesn't find it automatically the java home location may need to be specified in the settings -- http://www.pydev.org/vscode/ has more details) and Python 2.6 or newer.

By default it should pick the python executable available on the PATH, but it's possible to specify a different python executable through the settings on VSCode (see http://www.pydev.org/vscode/settings.html for details).

Below, I want to share some of the things that are unique in PyDev and are now available for VSCode users:

Niceties from PyDev when typing such as auto-adding self where needed (note that having the editor.formatOnType setting turned on is a requisite for that to work).

In-file navigation to previous or next class or method through Ctrl+Shift+Up and Ctrl+Shift+Down.

Now, the extension itself is not currently open source as PyDev... my target is making the best Python development environment around and all earnings will go towards that (as a note, all improvements done to PyDev itself will still be open source, so, most earnings from PyDev on VSCode will go toward open source development).

Monday, December 04, 2017

Ok, so, the target here is doing a simple extension with Visual Studio Code which will help in profiling the current module using PyVmMonitor (http://www.pyvmmonitor.com/).

The extension will provide a command which should open a few options for the user on how he wants to do the profile (with yappi, cProfile or start without profiling but connected with the live sampling view).

Now, after the user chooses how to start PyVmMonitor, the idea would be making any launch actually start in the chosen profile mode (which is how it works in PyDev).

After investigating a bit, I couldn't find out how to intercept an existing launch to modify the command line to add the needed parameters for profiling with PyVmMonitor, so, this integration will be a bit more limited than the one in PyDev as it will simply create a new terminal and call PyVmMonitor asking it to profile the currently opened module...

In the other integrations, it was done as a setting where the user selected that it wanted to profile any python launch from a given point onward as a toggle and then intercepted launches changing the command line given, so, for instance, it could intercept a unittest launch too, but in this case, it seems that there's currently no way to do that -- or some ineptitude on my part finding an actual API to do it ;)

Now, searching on the VSCode Python plugin, I found a "function execInTerminal", so, I based the launching in it (but not using its settings as I don't want to add a dependency on it for now, so, I just call `python` -- if that's wrong, as it opens a shell, the user is free to cancel that and correct the command line to use the appropriate python interpreter or change it as needed later on).

Some notes I took during the process related to things I stumbled on or found awkard:

After publishing the first time and installing, the extension wasn't working because I wrongly put a dependency from npm in "devDependencies" and not in "dependencies" (the console in the developer tools helped in finding out that the dependency wasn't being loaded after the extension was installed).

When a dependency is added/removed, npm install needs to be called again, it's not automatic.

When uploading the extension I had the (common) error of not generating a token for "all" ;)

Apparently there's a "String" and a "string" in TypeScript (or at least within the dependencies when editing VSCode).

The whole launching on VSCode seems a bit limited/ad-hoc right now (for instance, .launch files create actual launchers which can be debugged but the python extension completely bypasses that by doing a launch in terminal for the current file -- probably because it's a bit of a pain creating that .launch file) -- I guess this reflects how young VSCode is... on the other hand, it really seems it built upon previous experience as the commands and bindings seems to have evolved directly to a good design (Eclipse painfully iterated over several designs on its command API).

Extensions seem to be limited by design. I guess this is good and bad at the same time... good that extensions should never slow down the editor, but bad because they are not able to do something which is not in the platform itself to start with -- for instance, I really missed a good unittest UI when using it... there are actually many other things I missed from PyDev, although I guess this is probably a reflect on how young the platform is (and it does seem to be shaping up fast).

Wednesday, November 29, 2017

PyDev 6.2.0 is mostly a bugfix release, although it does bring some features to the table to such as adding the possibility of activating word-wrapping in the console and support for code-completion using the Python 3.6 variable typing.

Another interesting change is that pytest filenames are properly hyperlinked in the console (until now PyDev resorted to mocking some functions of pytest so that when it printed exceptions it used the default Python traceback format -- now that's no longer done).

Tuesday, November 07, 2017

PyDev 6.1.0 is now available for download. The major change in this release is in the code formatter, which can now deal with adding or removing blank lines so that code can properly conform to pep-8, besides having a number bugs fixed (see http:///www.pydev.org for more details).

Now, why use the PyDev code formatter at all when there are so many other options available? (i.e.: autopep8, yapf, PythonTidy -- and autopep8 is even already included by default in PyDev)

Well, the PyDev code formatter is unique in that it tries to do as few changes as possible to the code, so, it tries to conform to the coding format that the programmer uses, just fixing few (usually obvious) issues, such as spaces after comma, spaces in comments, operators or right-trimming lines, with an option to actually only fix only the lines actually changed.

-- for actually changing the indentation of statements or comments, PyDev has options which can be manually activated, such as wrap or unwrap statement -- through Ctrl+1, wrap statement or Ctrl+1, unwrap statement in the line which has the contents to be wrapper or unwrapped or Ctrl+2, w to wrap comments -- see: http://pydev.blogspot.com.br/2015/04/wrapping-docstringscomments-in-pydev.html.

Also, the PyDev code formatter is pretty fast, so, I don't have issues in letting the option to autoformat on save turned on (speed is the main reason why I added such a feature to the PyDev code formatter instead of going with autopep8 or integrating another code formatting tool).

Thursday, September 21, 2017

The new PyDev release is now out and offers some really nice features on a number of fronts!

The interpreter configuration now integrates with both pip and conda, showing the installed packages and allowing any package to be installed and uninstalled from inside the IDE.

Also, it goes a step further in the conda integration and allows users to load the proper environment variables from the env -- this is actually false by default and can be turned on in the interpreter configuration page when PyDev identifies an interpreter as being managed by conda by checking the "Load conda env vars before run" configuration (so, if you have some library which relies on some configuration you don't have to activate the env outside the IDE).

Another change which is pretty nice is that now when creating a project there's an option to specify that the project should always use the interpreter version for syntax validation.

Previously a default version for the grammar was set, but users could be confused when the version didn't match the interpreter... note that it's still possible to set a different version or even add additional syntax validators, for cases when you're actually dealing with supporting more than one Python version.

The editor now has support for subword navigation (so, navigating words as MyReallyNiceClass with Ctrl+Left/Right will stop after each subword -- i.e.: 'My', 'Really', 'Nice', 'Class' -- remember that Shift+Alt+Up can be used to select the full word for the cases where Ctrl+ShiftLeft/Right did it previously).

This mode is now also consistent among all platforms (previously each platform had its own style based on the underlying platform -- it's still possible to revert to that mode in the Preferences > PyDev > Editor > Word navigation option).

Integration with PyLint and isort were also improved: the PyLint integration now provides an option to search for PyLint in the interpreter which a project is using and isort integration was improved to know about the available packages (i.e.: based on the project/interpreter configuration, PyDev knows a lot about which should be third party/ library projects and passes that information along to isort).

In the unittest front, Robert Gomulka did some nice work and now the name of the unittest being run is now properly shown in the run configuration and it's possible to right-click a given selection in the dialog to run tests (Ctrl+F9) and edit the run configuration (to edit environment variables, etc) before running it.

Aside from that there were also a number of other fixes and adjustments (see http://pydev.org for more details).

Tuesday, August 15, 2017

This version now integrates the performance improvements which were done in PyDev.Debugger for 3.6 (which use the new hook available by Python and changes bytecode to add calls to the debugger so that there's less overhead during the debugging -- note that this only really takes place if breakpoints are added before a given code is loaded, adding or removing breakpoints afterwards falls back to the previous approach of tracing).

Another nice feature in this release is that isort (https://github.com/timothycrosley/isort) can be used as the default engine for sorting imports (needs to be configured in preferences > PyDev > Editor > Code Style > Imports -- note that at that same preferences dialog you may save the settings to a project, not only globally).

There were also a number of bug-fixes... in particular one that prevented text searches from working if the user had another plugin which also used Lucene in a different version was really nasty... http://www.pydev.org has more details on the changes.

This is also the first release which is signed with a proper certificate (provided by Comodo) -- so, it's nice that Eclipse won't complain that the plugin is not signed when it's being installed, although I discovered that it isn't as useful as I thought... it does work as intended for Eclipse plugins, but for Windows, even signing the LiClipse installer will show a dialog for users (there's a more expensive version with extended validation which could be used, but I didn't go for that one) and on Mac OS I haven't even tried to sign as it seems Comodo certificates are worthless there (the only choice is having a development subscription from Apple and using a certificate Apple gives you... the verification they do seems compatible with what Comodo gives, which uses a DUNS number, so, it's apparently just a point of them wanting more $$$/control, not really being more secure), so, currently Mac users will still use unsigned binaries (the sha256 is provided for users which want to actually check that what they download is what's being distributed).