PEP 8 -- Style Guide for Python Code Code should be written in a way that does not disadvantage other implementations of Python (PyPy, Jython, IronPython, Cython, Psyco, and such).For example, do not rely on CPython's efficient implementation of in-place string concatenation for statements in the form a += b or a = a + b. This optimization is fragile even in CPython (it only works for some types) and isn't present at all in implementations that don't use refcounting. In performance sensitive parts of the library, the ''.join() form should be used instead. This will ensure that concatenation occurs in linear time across various implementations.Comparisons to singletons like None should always be done with is or is not, never the equality operators.Also, beware of writing if x when you really mean if x is not None -- e.g. when testing whether a variable or argument that defaults to None was set to some other value.
PEP 20 -- The Zen of Python Abstract Long time Pythoneer Tim Peters succinctly channels the BDFL's guiding principles for Python's design into 20 aphorisms, only 19 of which have been written down. The Zen of Python Beautiful is better than ugly. Explicit is better than implicit. Easter Egg >>> import this Copyright This document has been placed in the public domain. Harold’s Corollary to Knuth’s Law Lately I’ve found myself arguing about the proper design of unit tests. On my side I’m claiming: Unit tests should only touch the public API. The goal is to make sure that the tests are as close to actual usage as possible. By contrast some programmers advocate that tests should be method-limited. This approach may sometimes let the tests be written faster; but not always. Would you believe performance? For instance consider this proposal from Michael Feathers: A test is not a unit test if:It talks to the databaseIt communicates across the networkIt touches the file systemIt can’t run at the same time as any of your other unit testsYou have to do special things to your environment (such as editing config files) to run it.Tests that do these things aren’t bad. More than 30 years ago Donald Knuth first published what would come to be called Knuth’s law: “premature optimization is the root of all evil in programming.”
Log message style guide Created 9 December 2002, last updated 6 February 2003 One of the fit-and-finish issues all systems developers need to address is the text of log messages. This is a log message style guide. Once your product ships, it will be in customers' hands. These log messages will be some poor customer's first view of you after a problem occurs. Simply being consistent in your log messages will go a long way toward making them seem professional and authoritative. When logging a problem performing an operation (for example, reading a record), say what couldn't be done: GOOD: Couldn't read record.BAD: Something happened? When announcing an operation (either an informational or trace message), say what is going to happen. GOOD: Reading transaction log.BAD: I think I'll read the transaction log.BAD: Step 17a Use normal sentence capitalization and punctuation. GOOD: Couldn't open storage file.BAD: Couldn't open storage fileBAD: Couldn't Open Storage FileBAD: COULDN'T OPEN STORAGE FILE Don't be flip.
MemoryImage database · application architecture tags: When people start an enterprise application, one of the earliest questions is "how do we talk to the database". These days they may ask a slightly different question "what kind of database should we use - relational or one of these NOSQL databases?". But there's another question to consider: "should we use a database at all?" One of the defining characteristics of enterprise applications is the need to store long term data, which naturally leads people to reach for a database. The key element to a memory image is using event sourcing, which essentially means that every change to the application's state is captured in an event which is logged into a persistent store. A familiar example of a system that uses event sourcing is a version control system. Event sourcing has many consequences, including the ability to rebuild past states. Against that you do have to ensure you can reliably store the events and process them. The most recent is LMAX.
Stringification Created 9 December 2002, last updated 6 February 2003 One of the greatest features of modern programming environments is also the most humble: ubiquitous stringification. When I first worked in Java, I didn't think much about the java.lang.Object.toString method. It seemed like a good idea, and made sense, but was sort of the low-tech sibling in the method list. It was hardly "computer science" to be able to turn an object into a string. It seemed almost like a patch over a language deficiency at first: "Why not just have a way to print objects?" Gradually, I understood. This may be one of those features you don't miss until it's gone. Being able to always stringify objects without a lot of rigamarole makes it much easier to use those object in "natural" ways. As described above, Java has the java.lang.Object.toString method, inspired by Smalltalk's asString method. The default implementations are boring, by necessity: what information could they use to print something interesting?
MongoDB for a large queuing system | kill the radio Our queuing system is different from others in that it supports dependencies. For instance, before one job completes, its four children have to complete first. This allows us to create jobs that are actually trees of items all processing in parallel. On a small scale, things went fairly well. We built the entire system out, and tested and built onto it over the period of a few months. Then came time for production testing. Without a doubt, MongoDB was the biggest bottleneck. This was pretty disappointing. So there’s my advice: don’t use MongoDB for evenly-distributed high-write applications. On a more positive note, for everything BUT the queuing system (which we did get working GREAT after throwing enough servers at it, by the way) MongoDB has worked flawlessly. TL,DR; MongoDB is awesome.
Fix error handling first Created 6 February 2003, last updated 24 January 2007 Often when unexpected errors first occur, I've found problems in the way the error is handled. This isn't surprising: error handling code is often the least-exercised part of your system, so it's natural that there are bugs in it. It is important to fix the error handling problems first, then the original error. Sometimes there is a whole chaing of problems started by the original error condition, then compounded as layers of error handling code mis-handle the condition. In any program, there will be code specifically designed to handle unusual situations, whether they be errors, exceptions, failed assertions, edge conditions, odd input, whatever. Estimates vary about what fraction of a large program is devoted to error handling, especially when different error handling techniques (status codes vs. exceptions, for instance) are taken into account. Always fix error handling before fixing errors. 1 [trace] Getting user id...2 [crit!]
Regular Expressions in Programming Environment Regular expressions are a way of describing patterns of text that can be useful for processing text documents or when looking for a pattern and possibly replacing it with another. Regular expressions are a very powerful tool indeed, and the best thing is that they go beyond just one programming language or tool. You’ll find Regex enabled applications everywhere. File renaming tools might use Regex to allow complex renaming operations; most IDEs support it, search tools as well. Once you master regular expressions, you’ll find tons of applications. What we are covering here are some of the basic principles of regular expressions. What are Regular Expressions? Regular Expressions are a way of defining a pattern to be replaces or processed in a body of text. Imagine you have a rather long document with a single repetitive misspelling say a name Mr. have been changed to – What one can do? The Basics Matching Repetitions Group
Python Sourced And what defines a 'python activist' anyway? Blowing up Perl installations worldwide? Ivan Van Laningham, June 2005, on comp. lang. pythonAs it seems to me, in Perl you have to be an expert to correctly make a nested data structure like, say, a list of hashes of instances. In Python, you have to be an idiot not to be able to do it, because you just write it down. Peter Norvig, August 2000, on comp.lang.functionalPython is more concerned with making it easy to write good programs than difficult to write bad ones. Unsourced On Python Excellent plan! The Zen of Python (from the output of "import this") Beautiful is better than ugly. External links