Before coming to Python, I did a lot of work in Java. Java is pretty good language and environment, but it is different than Python. Beyond the language syntax there’s a ton little differences to be aware of. Sometimes when we move from Java into Python it shows by some of the things that we do.
Here’s some things I’ve learned over the years, (or things that I’ve stubbed my toes on recently).
Getters and Setters
In Java, object-oriented is the name of the game. Everything is an object and accessing the fields of an object directly is not encouraged. Traditionally small methods called getters and setters are used to retrieve the values of fields.
Python has the ability to do object oriented programming. In that respect it is possible to create Python code that “looks” like Java code. While it will work, it will earn you some odd looks from your coworkers. Getters and setters are not common in Python, the community tends to favor just directly accessing fields.
I will note that there are certain situations where a getter/setter would be a better idea than accessing a field directly. For those situations check out this blurb about the @property decorator
Sometimes there are subtle things that you are used to in Java, but when you go from Java into Python you will find that things are not quite the same! In Java if you are iterating over a collection and you attempt to modify the collection (say deleting an element) you will get an exception.
In Python… you can actually get away with this! I learned this the hard way the other day when I discovered the cause of a bug that had been around for a couple of weeks.
Because of a typo, the list that we are iterating over is appended to with the output of a processing function. (Line 8)
The worst part of this was that we saw the results of this bug, but dismissed it as just bad data. Turns out it was bad data, but it was from us! I feel that if this code had been written in Java we would have caught this error a lot earlier.
Patterns and Architecture
Java systems and developers pride themselves on their usage of design patterns. In some cases these patterns are necessary and result in wonderfully expressive code that solves a problem in an elegant manner. Other times… Someone decided a pattern just had to be a part of the system.
Outside of Java many language communities reject patterns and Java’s abuse of them. I am on the fence on this one.
While I agree that Java projects can go nuts when it comes to implementing too many patterns, I also feel that the dynamic language community might be able to benefit from a few more patterns.
Having said that, if you are going to write Python, please try to keep the number of Factory Pattern objects to a minimum please. If your code starts to have names that look they were generated by the Enterprisifier, then it might be time to dial it back a bit. 😉
Edit: It has been pointed out that I have confused static and strong. For this section, I intended to say “Java is statically typed”. Shout out to reader Mark for noticing this.
strongly statically typed (e.g. you have to declare the type of a variable) and Python is dynamic. Being dynamic is awesome when it comes to being productive or prototyping code rapidly. It is less awesome when you find yourself peppering your code with isinstance() or type().
This is a fundamental difference between the languages that is neither good nor bad. It is just the reality of where you are working. Python 3.5 and up does offer “type hints”, but that is probably never going to be as strong of a guarantee as you would have with strong types (like Java).
Further tips on moving from Java into Python
As with most things in life, experience is the best teacher. The more Python code you write, the better you will adapt the Python way of doing things.
A great starting point would be to consult with a book like Effective Python. I read this book when it first came out and I refer to it often. I have found it to be a well written resource that offers many practical tips. Its amazing how many times this book has been referenced in conversations around the office.
Another suggestion: Use Rosetta code to see examples of how coding problems are solved in Python compared to Java. That is an awesome site that shows problems solved in many different languages.
Also, in the spirit of further practice check out Codewars. I’ve been using that site to do some daily warm up exercises before jumping into my regular coding. I’ve found it is an excellent way to get the brain warmed up and to be reminded of “other” ways to solve problems.