PythonArchive

     In Python 3, there are two types that represent sequences of characters: bytes and str. Instances of bytes contain raw 8-bit values. Instances of str contain Unicode characters. In Python 2, there are two types that represent sequences of characters: str and unicode. In contrast to Python 3, instances of str contain raw 8-bit values. Instances of unicode contain Unicode characters.      There are many ways to represent Unicode characters as binary data (raw 8-bit values). The most common encoding is UTF-8. Importantly, str instances in Python 3 and unicode instances in Python 2 do not have an associated binary encoding. To convert Unicode characters to binary data, you must use the encode method. To convert binary data to Unicode characters, you must use the decode method.      When you’re writing Python programs, it’s important to do encoding and decoding of Unicode at the furthest boundary of your interfaces. The core of your program...

This is the tenth post in my series of blog posts about Python decorators and how I believe they are generally poorly implemented. It follows on from the previous post titled  Performance overhead of using decorators , with the very first post in the series being  How you implemented your Python decorator is wrong . In the previous post I started looking at the performance implications of using decorators. In that post I started out by looking at the overheads when applying a decorator to a normal function, comparing a decorator implemented as a function closure to the more robust decorator implementation which has been the subject of this series of posts. For a 2012 model MacBook Pro the tests yielded for a straight function call: 10000000 loops, best of 3: 0.132 usec per loop When using a decorator implemented as a function closure the result was: 1000000 loops, best of 3: 0.326 usec per loop And finally with the decorator factory described in this series of blog ...

This is the ninth post in my series of blog posts about Python decorators and how I believe they are generally poorly implemented. It follows on from the previous post titled  The @synchronized decorator as context manager , with the very first post in the series being  How you implemented your Python decorator is wrong . The posts so far in this series were bashed out in quick succession in a bit over a week. Because that was quite draining on the brain and due to other commitments I took a bit of a break. Hopefully I can get through another burst of posts, initially about performance considerations when implementing decorators and then start a dive into how to implement the object proxy which underlies the function wrapper the decorator mechanism described relies on. Overhead in decorating a normal function In this post I am only going to look at the overhead of decorating a normal function with the decorator mechanism which has been described. The relevant part of th...

This is the eigth post in my series of blog posts about Python decorators and how I believe they are generally poorly implemented. It follows on from the previous post titled  The missing @synchronized decorator , with the very first post in the series being  How you implemented your Python decorator is wrong . In the previous post I described how we could use our new universal decorator pattern to implement a better @synchronized decorator for Python. The intent in doing this was to come up with a better approximation of the equivalent synchronization mechanisms in Java. Of the two synchronization mechanisms provided by Java, synchronized methods and synchronized statements, we have however so far only implemented an equivalent to synchronized methods. In this post I will describe how we can take our  @synchronized  decorator and extend it to also be used as a context manager, thus providing an an equivalent of synchronized statements in Java. The original ...