Instead of technical or depressing blog post I’ll give you these images. It happened somewhere around here.
Source Code Pro is a new font released by Adobe. It does wonders for technical fixed width and source code text readability. I highly recommend to use this font with your text editor, terminal and other software development tools (Especially if your eyes are getting old like mine).
UPDATE 2: I am not sure how subpixel antialiasing affects the screenshot quality. The images definitely have some LCD subpixel antialiasing if you zoom in. All screenshots were taken on Macbook Pro, OSX Mountain Lion, 1920 x 1080 external monitor (no retina).
Source Code Pro light variant text (preferred on OSX where the default font antialiasing does very fuzzy job):
Source Code Pro light variant black on white:
Source Code Pro (normal) text:
vs. Consolas text (Microsoft’s console font):
The font itself is also open source: download at Github for your Windows, OSX or Linux.
UPDATE: If you don’t like horizontal and vertical spacing you can fine tune them at least with iTerm 2:
The only downside I have found is that the bold Source Code Pro variant looks muddy with OSX font antialiasing. Thus, I had to disable iTerm 2 option “show bold text with bold font”. This is actually a legacy ANSI text formatting option and means the font brightness (grey vs. white, brown vs. yellow, red vs. pink) so no much harm done.
Here is a trick how one can print out variables more easily in Python.
Python has a locals() function which gives you back a dictionary of local variables within the function. Python string formatting, also called string interpolation, accepts dictionary like fillers. You can combine these two so that you do not need to explicitly pass input variables for the string formatting making your code more readable. This is very useful e.g. in the logging situations.
# -*- coding: utf-8 -*- # Python 2.6+ future compatibility declarations from __future__ import absolute_import, division, print_function, unicode_literals def my_function(): foo = 12 # NOQA bar = "Toholampi city coders - http://www.toholampi.fi" # NOQA baz = 3.0 # NOQA print("Foo %(foo)s, bar %(bar)s and baz %(baz)s went to a bar..." \ % locals()) # versus # print("Foo %s, bar %s and baz %s went to a bar..." % \ # (foo, bar, baz)) my_function()
Convenient, isn’t it?
Note about linting this kind of functions: pyflakes linter will complain about unused variables as it does not have function or module scope warning disable. # NOQA hints flake8 to ignore unused variable warning.
Sometimes running buildout for Plone and it ends up like this:
Getting required 'zope.testing==3.8.1' We have the distribution that satisfies 'zope.testing==3.8.1'. Getting required 'zope.event' required by z3c.widgets.flashupload 1.0c1. required by plone.registry 1.0. required by z3c.form 2.2.0. required by zope.component 3.4.0. We have a develop egg: zope.event 0.0 Getting required 'zope.dottedname' required by plone.registry 1.0. required by plone.app.registry 1.2. We have a develop egg: zope.dottedname 0.0 Getting required 'zope.schema==3.4.0' We have the distribution that satisfies 'zope.schema==3.4.0'. Getting required 'ZODB3==3.8.4' We have the distribution that satisfies 'ZODB3==3.8.4'. Getting required 'zope.i18nmessageid' required by z3c.formwidget.query 0.5. required by plone.directives.form 1.0b6. required by z3c.widgets.flashupload 1.0c1. required by plone.app.registry 1.2. required by z3c.form 2.2.0. required by zope.schema 3.4.0. We have a develop egg: zope.i18nmessageid 0.0 Getting required 'Products.statusmessages==3.0.3' We have the distribution that satisfies 'Products.statusmessages==3.0.3'. Getting required 'Products.CMFPlone==4.0b1' We have the distribution that satisfies 'Products.CMFPlone==4.0b1'. Getting required 'plone.autoform==1.0b2' We have the distribution that satisfies 'plone.autoform==1.0b2'. The version, 1.0b4, is not consistent with the requirement, 'plone.supermodel>=1.1dev'. While: Installing instance. Error: Bad version 1.0b4 ********************************************* Overwriting versions.cfg
It means that a package has dependencies which other packages in buildout configuration pin down to an incompatible, older versions. Usually the package which declares too new dependencies is not itself pinned down – you’ll automatically get the latest version from PyPi package repository. The solution is to figure out which of your automatically pulled in packages is one that is “too new”.
Based on this output it is almost impossible to figure out where is a version conflict and what package you have is requiring too new versions. This is especially true for old Plone 3.3.x buildout configurations.
However this little UNIX grep search might help you. It goes through all eggs requires.txt files which declare package dependencies in installed (thus far) eggs folder. EGG-INFO is a metadata folder found inside Python eggs – it contents is generated from setup.py when you release your egg for the distribution on PyPi. We will look for CMFPlone which is too new based on bin/buildout -vvv output (it says 4.x even though this buildout configuration is for Plone 3.x):
# The actual location of eggs/ folder depends on your installation grep -Ri --include="requires.txt" "CMFPlone" eggs/*
Looks like the culprit in our case is plone.app.registry.
Then you can go to plone.app.registry PyPi page. Look for a version which seems to be “old enough”.
Then pin down it in buildout.cfg:
eggs = ... plone.app.registry==1.0.1
… and your buildout happily churns forward again.