Indexes and Keys

In any programming language, the developer typically has a choice between two collection types — a list or a dictionary. They may be called something similar, depending on the language — array and hash-map for example. The list uses an index to access a given item in the collection while the dictionary uses a key. A key could be a number, or some other primitive construct in the language, but they're usually strings. There is one interesting distinction between indexes and keys. Indexes are allocated by the list whereas keys have to be dreamed up by the programmer. This is both good and bad. Good because keys are strings based on some concept. Indexes, by contrast aren't so intuitive to the developer when they need to look something up later. Should we just stick with dictionaries in our code, or our we introducing some hidden issues?

Python 3 Adoption

Python 3 is the first backward-incompatible version of the Python programming language. This incompatibility was intentional and necessary in order to fix a number of issues with Python 2. However, there are a number of Python developers who aren't happy with the changes introduced in Python 3. These complaints are reflected in the seemingly poor adoption of the next-generation Python. This didn't exactly come as a surprise to the creators of Python 3. This is why support for Python 2 will continue for years to come.

I'll admit, I wasn't exactly elated that Python 3 wouldn't be compatible with Python 2 applications. Who would be? You've spent months or years working out intricacies to yield a stable Python 2 application. This incompatibility would dictate that you throw it all away. Well, maybe not exactly, there are upgrading utilities to help convert Python 2 code to Python 3 code. Obviously this isn't going to fix the larger problem of not having supporting frameworks and libraries.

The selection of available Python 3 packages on pypi is slim but growing. Some important web application frameworks like Django and Twisted are missing. Developers that rely on these frameworks obviously aren't going to adopting Python 3 anytime soon. So why aren't these frameworks adopting Python 3? Because it is hard. It isn't exactly trivial to build a well-established, stable framework even in Python 2 which has been around for a while. Most of these frameworks will be Python 3 based at some point in the future while others probably have no intention of adoption.

In the mean time, write some Python 3 code that doesn't rely on frameworks. This is probably the best way to get familiar with the language. If you know another Python developer, show them some cool things you get working in Python 3. Also show them stuff that doesn't work. This all leads to more Python 3 code coming into existence. This could be a good opportunity to write a new framework for Python 3. Remember, there are many benefits brought about by the changes made in Python 3 that outweigh the familiarity of constructs you're used to using in Python 2.

Learning Python

Several years ago, the second edition of Learning Python was one of my first exposures to the Python programming language. Now the fourth edition of the book is available and is getting good reviews.

The latest edition has Python 3 reference material and takes the approach of inserting Python 3 content where necessary. I think that this is a good approach rather than treating the two languages as completely separate entities. Just because the two versions of the language aren't compatible with one another doesn't mean they are really that different.

If the fourth edition of the book is anything like what I remember from the second edition, I highly recommend it for anyone looking to learn the language.

Statically Typed Languages

Any programming language in existence today has primitive types that values can be defined as. An example of this would be an integer or a string. This holds true for both statically typed languages and dynamically typed languages. The differences between the two programming language varieties is that in statically typed languages, variables require at least a primitive type before they may be assigned a value. That is, you can't say that variable int_obj has a value of 10 before declaring that int_obj is going to store integer values. Additionally, once a variable has been declared to store certain types, it cannot store a different type. So our int_obj cannot decide to store "10".

The reason for doing this is so that the program can be compiled into machine code that is directly executable by the hardware. Otherwise, the it only serves as a limitation. So are statically typed languages dead? This obviously depends on context because the raw machine code performance is always going to be a requirement. But does this been that entire applications need to be built using a statically typed languages such as C? Probably not. Developing in these languages is no easy task and there are several other development factors to consider during development such as maintainability. Dynamically typed languages offer much more flexibility in both design and maintainability. But this comes at the cost of performance because dynamically typed languages need a virtual machine to execute programs.

Java is an interesting language because it was designed to help implement C++ style applications without the added complexity. Java, however, is still considered a statically typed language. Developers still need to declare the type of the construct before it is used. Java still does perform well, but it is still an interpreted language that is statically typed. This actually helps with the performance even though it is an interpreted language.

So is it possible to have a dynamically typed language that can still support the raw performance offered by statically typed languages? The best approach here is to have a dynamically typed languages which are extended by the low level constructs of statically typed languages.

Platform Independence In Dynamic Languages

In today's modern computing world, more and more applications are built in dynamic languages. These languages offer more platform independence than compiled languages do. This is because dynamic languages run inside a virtual machine that was compiled for the target platform. The end result is applications that offer more platform independence. Dynamic language virtual machines are becoming more prevalent on end-user systems these days. For instance you'll find a Java virtual machine just about everywhere. In cases where the virtual machine does not exist on the target platform, the virtual machine can be distributed along with the application. The main benefit of course is that once a dynamic language virtual machine is installed, the machine handles the majority of the platform dependent operations.

There are obvious limits to how independent a given application written in a dynamic language can be. This mostly depends on what the application does. Applications that use only the most fundamental features of the language have any chance of being truly platform independent. Realistically, a given application is going to want to take advantage of libraries or modules offered by the language in order to provide better functionality. For instance, most dynamic languages will provide a operating system module for low-level system operations. Not all functionality of this module will be supported on all platforms and there may be subtle behavioral differences in the operations supported across all platforms. It is the responsibility of the application to handle these scenarios.

The best way to handle these platform dependent anomalies is to define platform specific abstractions. This abstraction is illustrated below.



The base Controller class is abstract. It should never be instantiated. Only one of its children, WinController or LinuxController, should ever be instantiated. Therefore, the base and its children should only define functionality that differs among supported platforms.

Three Languages For Learning How To Develop Software

In an interesting discussion, the question of which programming language is best suited for teaching computer science students is raised. It is an interesting question because it seems that there isn't any real consensus among schools as to what the standard language should be. This brings up another question; should there be a standard language that should be taught to computer science students? Or should a more adaptive approach be taken and teach a language geared more toward some specialization?

I think the introductory-level courses need at least some level of language standardization amongst schools. Later on in the computer science program, if there is a specialization the student is interested in, the language best suited for that purpose should be taught. However, there are countless specializations a computer science graduate could strive to be an expert in. I don't think it is possible to realize them all, but the schools that teach these computer science programs should at least open a few broad categories of computer science specializations rather than just a single end point.

During the introductory courses of a computer science program, the concepts take the top priority. I think three languages could serve as a powerful tool in teaching these concepts. First, the C programming language. C allows for a good introduction to low-level programming concepts. It is also a good example of language design and is still heavily used in the industry. Second, the C++ programming language. C++ is a natural progression from C in order to introduce object-oriented concepts. Still heavily used in industry and still low-level. Lastly, the Python programming language. Python gives a good introduction to high-level languages. Not as heavily used in industry but is always gaining popularity. Python and C are highly interoperable.

Think Again About Promoting Your Language

Are you one to promote your programming language of choice? I know I am. This entry may in fact force anyone who promotes a given language and is not thoroughly in touch with the technical realities to reconsider what they are promoting. Lots of interesting data found here and and a very worth-while read.

C remains popular while Python is still low-key.

An interesting entry cites the C programming language as the most popular choice for new open source projects. There are also some other languages that followed C as popular choices. Python wasn't one of them.

So what does this mean? Absolutely nothing. It means that there are several existing and successful Python projects out there. Although I'm not a huge fan of some of the other languages mentioned, as a Python developer, I do like C. Python and C interoperability at the system level isn't too difficult to achieve.

Of course, this isn't a requirement. Ideally, if some new killer open source application written in C is made available, you can make bindings between it and your Python application.

Testing for length in dynamic languages

Testing for the length of some object in dynamic languages, or, statically-typed languages for that matter, is a common task in every single application. Especially in statically-typed languages. In cases where some task needs to be carried out for every object in a set, we simply iterate through that set. We perform the task needed on every object, possibly invoking some operation with the object as a parameter.

In Python, and other similar languages, it is fairly trivial to iterate over a set and is done quite often. For example.

#Python iterate.

list_obj=[1,[2,3],[4,[5,6],7],8,9,10]
for i in list_obj:
print i

Here, we have a simple list of integers and sub-lists. We iterate through this list and print its' elements.

Now, say we want to generate some HTML output for a web page. We need to display a list of all list elements on this HTML page. I'll implement a simple function to generate list elements.

#Python iterate.

list_obj=[1,[2,3],[4,[5,6],7],8,9,10]
html_list='<ul>%s</ul>'
temp_content=''

def generate_list_element(obj):
return '<li>%s</li>'%(str(obj))

for i in list_obj:
temp_content+=generate_list_element(i)

print html_list%(temp_content)

Here, we set up a temporary variable to hold all li tags generated by the generate_list_element() function. We also have the html_list template variable defined which, after the iteration has completed, will give us the final ul tag.

One problem with this approach is that if list_obj is empty, we have an empty ul element. I most cases, this isn't the desired output. The better solution would be to initialize the template based on what is available to the template. For example.

#Python iterate.

class MyHTML:
  list_obj=[1,[2,3],[4,[5,6],7],8,9,10]
  html_list=False
  template='<ul>%s</ul>'
  error='Error.  List is Empty.'

  @classmethod
  def generate_list_element(cls, obj):
      return '<li>%s</li>'%(str(obj))

  @classmethod
  def _set(cls, content):
      cls.html_list=cls.template%(content)

  @classmethod
  def set(cls, content):
      content and cls._set(content)

  @classmethod
  def get(cls):
      return cls.html_list or cls.error

temp_content=''
for i in MyHTML.list_obj:
  temp_content+=MyHTML.generate_list_element(i)
MyHTML.set(temp_content)
print MyHTML.get()

This code will produce the exact same output as the previous example. The main difference being that here, we can handle empty sets. I've better organized the code by introducing a class; MyHTML. This class defines an error message in the case of an empty list. The message isn't the important idea here. What is important is that MyHTML.error could be an empty string or invoke some other behavior to produce the desired output in the case of an empty set.

If you take a look at the main program, ignoring the class for now, you'll notice that we do not test for length. We simply iterate through our set and build our content. If the set is empty, the loop is not entered and that is our indicator of a false value. In the context of an alternate output based on an object having any elements or not, boolean logic should be used.

Just because we use the and and or operators doesn't make our code any less readable. It is encapsulated by our MyHTML class. In my opinion, the length of an object really only needs to be calculated for logic that "does this object have a length?" does not support.