Tag Archives: python

Raise or Return? (using exceptions, part 1)

Ever since I've been using exceptions, uncertainty has always been there: when are we better off with return codes? when is it smart to catch the exceptions? when should they better be left untouched and propagate higher? Create a separate exception class, or just pass an argument to the constructor?

cc-by-sa Jason McHuff

During the recent few years, I've been gathering some best practices I learned from my peers and by experience, which I'll dump here to a short series of posts. I hope it'll help to provoke some discussion on this rather important design matter. As it's a highly debatable matter, discussions are more effective than trying to declare the ultimate truth of proper usage of exceptions.

Most of my experience in this area is related to Python, but I believe the same discussion usually applies to all dynamic languages, and possibly to languages that use throw rather than raise.

Enough disclaimers, let's get started. An easy one for starters:
Continue reading

pylint Vim plugin update (0.24.0 support)

[Executives' summary (in case any executive uses Vim) - get this updated pylint.vim for compatibility with pylint 0.24.0 changes] 

Integrating Python code checker into Vim is really cool. It lets Vim provide (relatively) quick feedback on your code, be it a conventions warning or syntax error. That, in my opinion, increases coding productivity slightly.

The problem is, that configuring the vim-pylint integration is hell. for two reasons mainly:

  1. Doing it manually requires understanding of the unpleasant errorformat syntax and some other vim tricks.
  2. No good zero-setup plugin is available: official pylint.vim is unmaintained. I used to use this fork, but its not really active anymore.

Specifically, since I upgraded to latest pylint (0.24.0),  Vim stopped showing pylint's hints. That's because pylint's output was modified to contain the column number as well.

I've re-forked it, and updated it to support pylint 0.24.0. Note that it will probably fail with older versions. Please try it and send feedback (you can comment this post if easier).

Configuring ctags for Python and Vim

Exuberant ctags is a cool, language-agnostic tool for creating tag files for your source code. Nice editors such as Vim, could use these tag files to implement the much needed 'jump to definition' feature.

Ctags is awesome, it supports Python, and is supported by Vim. It seems that the world is perfect and there's no reason to write a post about configuring it. Well... almost.

ctags has a little downside when using Python: it recognizes import lines as a definition, at least as of ctags v5.8. No need to explain why it's annoying in most cases. After 2 years of suffering, I've found it's possible to overcome this simply by adding the --python-kinds=-i option to the command line, or better: to ~/.ctags.

And just to make it complete, a quick cookbook style for setting everything up and using:

  1. Install ctags
    e.g. aptitude install exuberant-ctags
  2. Configure ctags.
    Add to ~/.ctags the following, one option per line:

    1. --python-kinds=-i
    2. optional: --exclude=<partial names of bad files/directories>. e.g. --exclude=*/build/* to exclude all files inside 'build/' directories
  3. Add a cron to rebuild tags, for instance:
    1 * * * * ctags -R -o ~/mytags ~/src
  4. Configure vim:
    add to ~/.vimrc: :set tags=~/mytags
  5. Use Vim:
    1. vim -t <tag name> to open vim straight on the tag
    2. Ctrl+] to jump to tag when over a word
    3. Ctrl+T to pop back
    4. :tselect or :stselect to open
    5. :tnext, :tprev to go to next/prev tag finding
    6. :help tags for more 🙂

Few IronPython impressions and a quick guide

I've been messing with IronPython lately. It's a .NET, microsoft-supported [stop throwing tomatoes at me! Ms-PL is an OSI-recognized OSS license! Ouch, stop that!] implementation of Python, somewhat like Jython is a Java implementation. The same person is behind them both, by the way 🙂

What is it good for? Well, accessing the whole .NET framework with Python code is quite a strong feature. IronClad project aims to allow accessing CPython (the popular implementation) binary modules, not sure how mature it is.

First impressions? 2.0RC2 seems pretty mature. Most of the "random" .NET classes I've been trying out seemed to work flawlessly. Load time is a bit slow. But all in all, it seems pretty good.

And now to few specific notes, that a CPython user might need as of version 2.0RC2:

Loading .NET assemblies howto

note that mscorlib is needed for many common namespaces, such as Microsoft.Win32. In MSDN, the "assembly name" is specified for each namespace, so it's easy to find out.

Python logging module bug

The famous logging module currently throws an exception instead of printing lines. Here's a workaround till they fix it:

[see Michael's comment below]
_winreg module problem with REG_BINARY type

The CPython _winreg implementation works fine, however in IronPython there's currently a little problem: "high ascii" (>128) chars are getting screwed because of some converting/encoding problem (uses System.Text.Encoding.ASCII which is 7bit aware). My workaround was to use directly the Microsoft.Win32.Registry implementation, and manually convert the returned Microsoft Byte Array to native Python string of bytes. If you need the code, comment me and I'll add it.

Compiling to DLL/EXE

I was looking for some "py2exe" compiler, but found out that the compiler itself is available as an IronPython class, and anyone can call it from their own Python script to fit their needs. Still, I use the pyc code (command line compiler). Note: find the latest version of this script, cuz old versions (IronPython v1.x don't fit!). Current latest hides in "IronPython 2 Beta 4" release.

Note: sometimes EXEs don't behave exactly the same as in the interpreter:

  • sys.argv bug: would probably be fixed soon
  • "clr.AddReference()" lines are sometimes (always?) not needed when using the interpreter, but are always required in EXE.

I find a "make" system pretty needed for IronPython.

Writing GUI

Windows.Forms is an integral part on .NET, and as such, is native to IronPython. IronPython Studio aims to allow nice GUI drawing tool (ok ok, an IDE). Still a bit buggy (I've lost 1hr annoying-design-work cuz it wasn't saved well), but it surely helps designing.


Debugging tools: haven't checked that area yet.

Sleep now.