Uthcode

This is summary of the Debugging chapter in The Practice of Programming by Brian Kernighan and Rob Pike. It was an absolute pleasure for me to read this paragraph, I have spent tons of time in debugging issues both in CPython and at work. The master programmers provide a great insight into the process of Debugging.

With the right attitude debugging can be fun, like solving a puzzle, whether we
enjoy it or not, debugging is a art that you need to practise regularly. Still,
it would be nice, if bugs didn't happen, so we try to avoid them by writing
code well in the first place.  Well written code has fewer bugs to begin with
and those that remain are easier to find.

Once a bug has been seen, the first thing to do is to think hard about the
clues it presents. How could it have come about? Is it something familiar? Was
something just changed in the program? Is there is something special about the
input data that provoked it? A few well chosen test cases and few print
statements in the code may be enough.

If there aren't any good clues, hard thinking is ...

Recently I spent good amount of time thinking does rigorous reviews on code style really matter? I often felt that style was personal and there is no authoritative statement be made on style factors of code. While this is true, I still appreciate and feel motivated when the code which we read presents itself clearly and unambigiously. Even the difficult algorithms if presented well in the code are very easy to follow.

I found very enlightening thought on code style in the book The Practice of Programming by Brian W. Kernighan and Rob Pike.

But why worry about style? Who cares what a program looks like if it works?
Doesn't it take too much time to make it look pretty? Aren't the rules
arbitrary anyway?

The answer is that well written code is easier to read and to understand,
almost surely has fewer errors and is likely to be smaller code than that has
been carelessly tossed together and never polished. In a rush to get programs
out of the door to meet some deadline, it's easy to push style aside, to worry
about it later. This can be a costly decision.  Sloppy code is bad code ...

During Pycon 2013, twitter (Brian Wickman specifically) conducted a short programming contest. When I initially saw the problem I thought it was a A* search problem seeing that it was closely related N-puzzle solver. I tried to solving that using A*, but I could not go any far and implemented a horribly wrong solution in 2+ hours I spent on the problem.

Later when the contest got over, I looked at some of the submissions and I was pleasantly surprised at some of the quality submissions that were coming through. All of them had spent couple of hours for solving that and were able to crack down the solution pretty quickly.

After I failed to come with a good solution and when I looked at the solution (submitted by the winner Maria Levin and approached in way by Brian and few others too) and I felt this was a wonderful problem in the first place and the solution can be approached in a very interesting way.

Before we go further, here is the problem that was given.

Go ahead and try for yourself if you are interested. After trying, when you return, you will realize that a good solution can ...

My Quick Notes from Python language summit.

Every year, Python language developers meet during the language summit to discuss about the improvements in the language and the ecosystem. I caught today's summit from the point when, Nick Coghlan discussing about the Packaging.

He gave the details about the Meta data required for Python Packages.

Metadata for Python Software Packages 2.0 http://www.python.org/dev/peps/pep-0426/

Next Brett Canon took over the discuss the XML security issues and pointed out Christian Heimes solution to deal with that. A General discussion ensued on security fixes and released.

The diffusedxml and diffusedexpat library which got mentioned is here:

http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html

Next, Guido discussed how yield from and Greg Ewing's use cases construct led him to think about the asynchronous programming support. The tulip asynchronous API reference is going to be very similar Twisted' inline callbacks. The most interesting thing being, replaceable event loop support.

Guido terms this as am ambitious attempt, starting with clean slate and not thinking about backwards compatibility.

http://www.python.org/dev/peps/pep-3156/

Having used with Twisted for 2 years, for an internal project at Akamai, I ...

In web application development you may want to use an image in a base64 encoded fashion rather than loading the image directly.

The img src tag supports a data:image/png;base64 format and browsers can display the image for you.

Look here for an example of how this is done - http://jsfiddle.net/phoe6/vJ3pM/

Now, in order to convert an image from .png format to data:image;base64 format, you can do it like this using python.

import base64
with open('golden_stars.png','rb') as img:
    encoded_str = base64.b64encode(img.read())

There is a lot of interest in this topic recently when PyPy and Armin Rigo rekindled this late last year. Since then, people have been excited about this and waiting to see if some new results show up in this area. My most recent tryst with that terminology was in another general tech blog called Good Math and Bad Math , published by Mark CC. That article does an excellent job in providing an high level overview of requirement of concurrency, need for atomicity and how STM helps.

Most often, I tend to understand things better when I can relate to things which I already know.

STM is trying to utilize the practical wins we have seen in DVCS world and in the database world where we can have atomic operations as Transactions. Both have been there for quite sometime and world has seen practical usages of these. I come to know that efficient transactions in Databases is still an open problem, but for all practical purposes, good databases have gotten this going.

Transaction will represent a series of actions which will be performed together and they provide atomicity. That is either all of them will be accomplished or none of ...

I was glancing through what's new in 2.2 and found an interesting historical titbit about generators in Python.

The idea of generators comes from other programming languages, especially Icon (http://www.cs.arizona.edu/icon/), where the idea of generators is central. In Icon, every expression and function call behaves like a generator. One example from “An Overview of the Icon Programming Language” at http://www.cs.arizona.edu/icon/docs/ipd266.htm gives an idea of what this looks like.

sentence := "Store it in the neighboring harbor"
if (i := find("or", sentence)) > 5 then write(i)

In Icon the find() function returns the indexes at which the substring “or” is found: 3, 23, 33. In the if statement, i is first assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon retries it with the second value of 23. 23 is greater than 5, so the comparison now succeeds, and the code prints the value 23 to the screen.

It further goes on to say that Generators are not central concept in Python, as it is for Icon, but has gotten new properties like you can store the state in ...