Vision on Django/Python 8
I have relatively recently begun to work with django and python, because heard many good things about them from different people. After this six month, I have already looked enough at the possibility of these tools (since worked on a real application rather than the application of the examples), and therefore decided to describe my vision. However, I do not pretend to be experts in these technologies and I understand that many things I do not know, and perhaps because of that I have and have the same impression.
So, what I like and dislike in django (considered a version which works on google appengine).
I like:
- a dynamic of python and that I do not need to restart the server to look on result of resent changes
- handy mechanism for parsing the URL and retrieving parameters from it
- mechanism for working with JSON
I dislike:
- impossible to compile whole application and thus:
- during testing and debugging we are finding and fixing errors, which could be found during compilation
- hard to make refactoring, because after renaming method or property it is hard to find all places, on which is affected by this changes
- impossible to validate html, which contains django markers
- there is not good IDE, which provides all necessary functionality, e.g. navigation via methods, “find usage” feature, suggestion mechanism for fields and methods, etc.
- howes, because code is not structured:
- there are a lot of things, which are implemented as functions. So modules looks like as container for huge amount of functions and therefore a lot of files contains huge amount of code lines. It makes harder reading and analysis of code.
- there are not service term. There are functions for handling URLs, which contains application’s business logic, but there is not services.
- there are not data access objects. It is possible to call find_by_id(..) or all(..) methods in entities, but there are not custom finders and it makes duplicate parts of code.
- poor support of transactions – in google appengine you should manually collect all entities, which should be updated or deleted, and after that call method for making these changes in transaction. In other words django does not support “Unit of work” pattern, which is realized in Hibernate or other similar frameworks.
- poor caching mechanism – you should manually put/get/remove objects in/from cache. For example in Hibernate or TopLink you need to configure cache for objects and it covers a lot of variants.
- for writing good application you should write good structured code (language does not require it) and it required good self-organization from developers. Moreover if you code is not good organized then it will be hard to fix it, because impossible to make good refactoring.
- not convenient to work with localization – you should make a lot of steps for translate you application on other language: you need to grab strings, compile messages and put in specific place. And in addition configuring all required things takes some time especially on windows where you don’t have various utilities needed.
So I think that django/python is suitable for small-medium application or prototypes. I think that all advantages of dynamic language will be slaughtered complexity of support for medium-big application.
Am I wrong?
Ivan, I think part of the article is not a comparison, but rather impression of non-comfortable things. Of course django and python has different targets in compare with other frameworks and languages, but some general things are really annoying as far as I understood from the article.
The thing is that Django/Python uses other paradigms that you used to. That makes you confusing but it doesn’t make Django/Python worse. It is completely different from Java you mentioned – it is interpreted language with imperative, object-oriented, functional programming paradigms included.
You may try to use your experience in other language here, but to achieve good results in Python you should use Python and Django patterns.
Just to cover some of your points:
> during testing and debugging we are finding and fixing errors
In Python unit, functional and code coverage tests are used to check that your code works right. Anyway, compiler finds obvious bugs only.
> hard to make refactoring
I’d say easy refactoring is a feature of Java, not a disadvantage of Python
I know no languages other than Java that has so powerful refactoring tools.
> impossible to validate html, which contains django markers
Django template engine was designed to generate any type of text file – TXT, HTML, XML, CSV, etc. So it just cannot be compatible with HTML validators. You should validate the generated HTML, not templates. By the way, validating templates without actual content seems nonsense because HTML elements and their attributes may be changed by provided data – ex.:
{% for div in divs %}{% endfor %}
> there is not good IDE
You should try Eclipse with Python extensions – it is known to be the most advanced IDE for Python. I use Geany that has fine syntax highlight and some features you mentioned.
> there are a lot of things, which are implemented as functions
Right! Django uses functional paradigm for views. It gives you a great flexibility and explicit code. But it doesn’t make code bigger comparing to object-oriented implementation.
> there are not service term
What is a service? What it is for? What is the difference between application and service? It seems the difference is artificial.
> there are not data access objects. It is possible to call find_by_id(..) or all(..) methods in entities, but there are not custom finders and it makes duplicate parts of code
Are you talking about auto-generated methods for finding objects like find_by_name(..), find_by_description(..) ? Anyway, as far as I know Google AppEngine has non-standard ORM engine that is considerably different from Django’s one.
> poor support of transactions
Django has great support of transactions using decorators explained on http://docs.djangoproject.com/en/dev/topics/db/transactions/ . The typical approach is to use @transaction.commit_on_success over view function or @transaction.commit_manually + transaction.commit()/transaction.rollback()
> poor caching mechanism
Django has nice caching – ORM is cached automatically (DB is not touched for the same queries) and you can store any custom data in cache having complete control over it.
> I do not need to restart the server to look on result of resent changes
In typical Django production installations (behind Apache or another web server) you have to reload the application somehow.
It is strange that you didn’t cover one of the biggest advantage of Django/Python – its clean and powerful syntax that makes the code compact and readable.
Reposting Django template example:
{% for div in divs %}[div id='{{ div.id }}' {{ div.attr_value }}='{{ div.attr_value }}']{% endfor %}
I totally understand that Django/Python is not Java and it has our approach and best practice. In this post I have only described my our feeling of using Django/Python within Google Appengine (may be signle Django/Python is better).
Anyway thanks for your comments and please find below my view on them:
> In Python unit, functional and code coverage tests are used to check that your code works right. Anyway, compiler finds obvious bugs only.
I think that compilation and unit testing are completely different things. Yes, simple compiler finds only obvious bugs, but what is a reason to run tests or application if it contains such bugs? Also I’d note that there are some situation when you only need to know that all application is compatible. Also compilation task less time than execution of all tests.
> I’d say easy refactoring is a feature of Java, not a disadvantage of Python I know no languages other than Java that has so powerful refactoring tools.
Refactoring is very useful and powerful tool. It is used in such popular programming languages as Java, .NET, C++, ObjectiveC.
> Django template engine was designed to generate any type of text file – TXT, HTML, XML, CSV, etc. So it just cannot be compatible with HTML validators. You should validate the generated HTML, not templates. By the way, validating templates without actual content seems nonsense because HTML elements and their attributes may be changed by provided data – ex.: {% for div in divs %}{% endfor %}
Yes, it is cool that django template supports a lot of types of file. Anyway HTML is one of most useful types. So it will be very good to have mechanism for validation it. For example you forgot to close for by {% endfor %} and you will spend a lot of time on finding this error, but validator can do it in 1 sec.
By the way JSP (Java Server Pages) also supports such syntax, but now it is already bad practice.
> You should try Eclipse with Python extensions – it is known to be the most advanced IDE for Python. I use Geany that has fine syntax highlight and some features you mentioned.
Ok, thanks – I’ll try them.
> Right! Django uses functional paradigm for views. It gives you a great flexibility and explicit code. But it doesn’t make code bigger comparing to object-oriented implementation.
Yes and many developers use this paradigm in Java or .NET using static-methods. There are a lot of advantages and disadvantages of it and I don’t think that it is good place to discuss it.
Also I think that size of code is not good criteria, because developer spend on 20% of his time on writing code.
> What is a service? What it is for? What is the difference between application and service? It seems the difference is artificial.
Service is a term of Service Oriented Architecture.
> Are you talking about auto-generated methods for finding objects like find_by_name(..), find_by_description(..) ? Anyway, as far as I know Google AppEngine has non-standard ORM engine that is considerably different from Django’s one.
Ok, but I’m talking about Django within Google AppEngine.
> Django has great support of transactions using decorators explained on http://docs.djangoproject.com/en/dev/topics/db/transactions/ . The typical approach is to use @transaction.commit_on_success over view function or @transaction.commit_manually + transaction.commit()/transaction.rollback()
It is better, but it does not cover all needs and unfortunately Google AppEngine does not support it.
> Django has nice caching – ORM is cached automatically (DB is not touched for the same queries) and you can store any custom data in cache having complete control over it.
Cool, but Google AppEngine supports only manual caching mechanism.
> In typical Django production installations (behind Apache or another web server) you have to reload the application somehow.
So Google AppEngine provides some benefits
> It is strange that you didn’t cover one of the biggest advantage of Django/Python – its clean and powerful syntax that makes the code compact and readable.
Unfortunately, I don’t think than syntax is so cool.
Here is one interesting IDE for python/django. I’m going to try it.
Serge, let us know about your test of Pycharm. Its looks very tasty, but I was upset about its flexibility comparing to Eclipse.
I agree with Artem.
Python – is another developing philosophy and its hard to make concurrent comparing to Java. Python requires more qualification and accuracy with huge projects. Thats make it hard to use at start. You need to rebuild your mind after typed language to think more efficient in python style.
And of course as you mentioned – this article was written in view of Google App Engine. GAE makes a lot of limits to original Django. And these limitations is more to GAE than to Django.