Python – first experiences

I’ve started using Python much more these days as I begin to switch to Tellurium as the standard modeling platform. Python is of course very popular and so I expected a very modern language which to a large degree it is. However, I’ve found, so far, two disappointing aspects which I think is related to Python’s age.

The first is that there is no way to make variables or methods in Python classes private. This is a common facility is all modern languages including some old ones such as Object Pascal. All fields in a Python class are visible. When you ask seasoned Python users you get two responses: the religious one and the practical one. The religious one says that hiding details of a class is overrated and as gentlemen we should respect the fact that some fields in a class, though accessible, should not be touched. The practical response is to add an underscore to every variable that should be private and hope that the IDE you’re using recognizes this convention and hides the field from you (likewise humans will hopefully do the same). Today we are more enlightened and recognize the virtues of Data Encapsulation.

The next problem I came across which really annoyed me since I am so used to it in other languages, is the inability to define multiple constructors. Strictly speaking there is only one constructor in Python, that strange concoction of letters, __init__.. To get round this limitation Python developers will use classmethods or go into overkill and use factory methods.

These limitations reflect to some degree the age of Python which was conceived in the late 1980s. I’ve seen the same thing in R (developed again in the late 1980s but whose origins can be traced back as far as the 1970s) where the language is even more archaic. The problem is of course, once a language becomes popular a huge investment will have been made in developing support libraries which makes it very difficult to transition to a more modern language. We’ve seen this of course in FORTAN and COBOL, both conceived in the 1950s but still used. At the moment I don’t yet see a new scripting language to replace Python but I am sure we’ll see something emerge in the next 5 to 10 years.

This entry was posted in General Science Interest, Programming, Software. Bookmark the permalink.

2 Responses to Python – first experiences

  1. hsauro says:

    I have used multiple constructors with Delphi and it can be convenient when you need to construct slightly different variants.One example I had in python is I have a class that managed a data series (labelled array). Such a dataseries can either be created by the class itself or a dataseries can be obtained from another source and passed to the class.

    In Delphi I would do something like:

    ds := TDataSeries.Create()
    ds := TDataSeries.Create (other source)

    This isn’t very good example however because as you mentioned this can be achieved with default parameters in python but one could imagine when there are more arguments, default parameters can become more difficult to manage. I need to dig out the actual case where I needed to overload the constructor.

  2. Leif says:

    hsauro, I also ran into some nuisances when I embraced Python. I agree, Python lacks traditional encapsulation, but encapsulation exists despite missing keyword modifiers.

    Aside from name mangling and module access, the property decorator may be useful to you. It lets you make class members private. Missing modifiers may stem from Python’s age, but implementing keywords in later versions isn’t difficult. I wrote a little about missing access modifier keywords: http://allofthethings.org/missing-in-python/4/#Python_does_not_support_access_modifiers. You might also want to review the other pages on that article.

    What would you like to achieve using multiple constructors? Duck typing and default arguments eliminate the need for method overloading, and the single responsibility principle narrows a class’s scope to a tolerable amount. Sadly, conventional method overloading is something that would be difficult to implement into Python. That’s not to say you’re left with using ugly hacks though.

Leave a Reply

Your email address will not be published.