This is a nifty trick when working with PyDev...
When you're writing docstrings it's usually pretty annoying having to manually wrap the contents of the string to fix inside a proper number of columns: say your standard is 80 columns and you've just written 5 lines of comments to fit in that, then, you decide to edit and add something in the middle: there it goes: you have to reindent all the lines below so that the block is nice again.
Well, PyDev has an utility for that: put your cursor on that block and do Ctrl+2, W (i.e.: press Ctrl+2 and type the char W later on). Doing that will fix your comment block to fit in the number of columns available (note that it works for code in docstrings and comments alike).
To give an example, say you have the code below:
Just place the cursor in the block, use Ctrl+2, W and voila, you get:
Hope PyDev users enjoy the trick (aligning those manually is definitely on the annoying group).
As a note, to configure the number of columns to be wrapped to go to preferences > general > editors > text editors and change the 'print margin column'.
To finish, Ctrl+2 has other interesting things (if you just press Ctrl+2 and wait a bit, a popup with the options will appear).
Thursday, April 23, 2015
Tuesday, April 21, 2015
Type hinting on Python
If you missed it, it seems right now there's a long thread going on related to the type-hinting PEP:
https://mail.python.org/pipermail/python-dev/2015-April/139221.html
It seems there's a lot of debate and I think the outcome will shape how Python code will look some years from now, so, I thought I'd give one more opinion to juice things up :)
The main thing going for the proposal is getting errors earlier by doing type-checking (which I find a bit odd in the Python world with duck-typing, when many times a docstring could say it's expecting a list but I could pass a list-like object and could get fine with it).
The main point raised against it is is that with the current proposal, the code becomes harder to read.
Example:
def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) -> List[Tuple[int, int, int]]:
Sure, IDEs -- such as PyDev :) -- will probably have to improve their syntax highlighting so that you could distinguish things better, but I agree that this format is considerably less readable. Note that Python 3 already has the syntax in-place but currently it seems it's very seldomly used -- http://mypy-lang.org/ seems to be the exception :)
Now, for me personally, the current status quo in this regard is reasonable: Python doesn't go into java nor c++ land and keeps working with duck-typing, and Python code can still be documented so that clients knows what kinds of objects are expected as parameters.
I.e.: the code above would be:
def zipmap(f, xx, yy):
'''
:type f: callable(tuple(int, int))->int
:type xx: list(int)
:type yy: list(int)
:rtype: list(tuple(int, int, int))
'''
Many IDEs can already understand that and give you proper code-completion from that -- at least I know PyDev does :)
The only downside which I see in the current status quo is that the format of the docstrings isn't standardized and there's no static check for it (if you want to opt-in the type-checking world), but both are fixable: standardize it (there could be a grammar for docstrings which define types) and have a tool which parses the docstrings and does runtime checks (using the profiler hook for that shouldn't be that hard... and the overhead should be within reasonable limits -- if you're doing type checking with types from annotations, it should have a comparable overhead anyways).
Personally, I think that this approach has the same benefits without the argument against it (which is a harder to read syntax)...
If more people share this view of the Python world, I may even try to write a runtime type-checking tool based on docstrings in the future :)
https://mail.python.org/pipermail/python-dev/2015-April/139221.html
It seems there's a lot of debate and I think the outcome will shape how Python code will look some years from now, so, I thought I'd give one more opinion to juice things up :)
The main thing going for the proposal is getting errors earlier by doing type-checking (which I find a bit odd in the Python world with duck-typing, when many times a docstring could say it's expecting a list but I could pass a list-like object and could get fine with it).
The main point raised against it is is that with the current proposal, the code becomes harder to read.
Example:
def zipmap(f: Callable[[int, int], int], xx: List[int], yy: List[int]) -> List[Tuple[int, int, int]]:
Sure, IDEs -- such as PyDev :) -- will probably have to improve their syntax highlighting so that you could distinguish things better, but I agree that this format is considerably less readable. Note that Python 3 already has the syntax in-place but currently it seems it's very seldomly used -- http://mypy-lang.org/ seems to be the exception :)
Now, for me personally, the current status quo in this regard is reasonable: Python doesn't go into java nor c++ land and keeps working with duck-typing, and Python code can still be documented so that clients knows what kinds of objects are expected as parameters.
I.e.: the code above would be:
def zipmap(f, xx, yy):
'''
:type f: callable(tuple(int, int))->int
:type xx: list(int)
:type yy: list(int)
:rtype: list(tuple(int, int, int))
'''
Many IDEs can already understand that and give you proper code-completion from that -- at least I know PyDev does :)
The only downside which I see in the current status quo is that the format of the docstrings isn't standardized and there's no static check for it (if you want to opt-in the type-checking world), but both are fixable: standardize it (there could be a grammar for docstrings which define types) and have a tool which parses the docstrings and does runtime checks (using the profiler hook for that shouldn't be that hard... and the overhead should be within reasonable limits -- if you're doing type checking with types from annotations, it should have a comparable overhead anyways).
Personally, I think that this approach has the same benefits without the argument against it (which is a harder to read syntax)...
If more people share this view of the Python world, I may even try to write a runtime type-checking tool based on docstrings in the future :)
Wednesday, April 15, 2015
PyDev 4.0 released. Yay!
PyDev just reached version 4.0 --- after 11+ years that's not so much, is it? ;)
The major improvement in this release is that PyDev can now unpack compound types when doing code-completion (i.e.: list(str), dict(int:str), etc).
The screenshot below shows a completion unpacking types by analyzing the current scope:
The second example shows a completion unpacking types by analyzing a docstring (see: http://pydev.org/manual_adv_type_hints.html for more details on the formats supported).
This release also enables Unicode literals and Byte literals to have different colors, so, it's easy to spot what you're working with (and it should respect the semantics of Python 2 from __future__ import unicode_literals and Python 3).
Another nice feature for those that work more in the interactive side of Python is that PyDev now allows users to define a template to send a custom command to the interactive console.
PyDev already has an F2 binding which sends a line to the console, but let's say that you do something else a lot in the console (such as plot(variable)). With this feature you can bind something as Ctrl+F2 to send the selected text as plot(${text}) to the console (the screenshot below shows how that configuration would be achieved).
Also, the PyDev update site is now hosted on http://bintray.com -- note that the update site urls didn't change, so, this change should (hopefully) be imperceptible to end-users...
There are also other nice things (see http://pydev.org for more details).
To finish, a special thanks to all the PyDev supporters (it definitely wouldn't be possible without your help -- for those that want to help supporting it, please access the related links at http://pydev.org).
The major improvement in this release is that PyDev can now unpack compound types when doing code-completion (i.e.: list(str), dict(int:str), etc).
The screenshot below shows a completion unpacking types by analyzing the current scope:
The second example shows a completion unpacking types by analyzing a docstring (see: http://pydev.org/manual_adv_type_hints.html for more details on the formats supported).
This release also enables Unicode literals and Byte literals to have different colors, so, it's easy to spot what you're working with (and it should respect the semantics of Python 2 from __future__ import unicode_literals and Python 3).
Another nice feature for those that work more in the interactive side of Python is that PyDev now allows users to define a template to send a custom command to the interactive console.
PyDev already has an F2 binding which sends a line to the console, but let's say that you do something else a lot in the console (such as plot(variable)). With this feature you can bind something as Ctrl+F2 to send the selected text as plot(${text}) to the console (the screenshot below shows how that configuration would be achieved).
Also, the PyDev update site is now hosted on http://bintray.com -- note that the update site urls didn't change, so, this change should (hopefully) be imperceptible to end-users...
There are also other nice things (see http://pydev.org for more details).
To finish, a special thanks to all the PyDev supporters (it definitely wouldn't be possible without your help -- for those that want to help supporting it, please access the related links at http://pydev.org).
Subscribe to:
Posts (Atom)