5 ms·

It's not clear to me whether this "excessive complexity" has an actual performance impact or is just a subjective measure of complexity. Django, one of the wor

It's not clear to me whether this "excessive complexity" has an actual performance impact or is just a subjective measure of complexity. Django, one of the worst offenders according to your chart, also happens to be a mature project in wide use that works really well and handles most edge cases where, perhaps, some "less complex" frameworks would fall down. So what does this measurement mean in practical terms? How should I balance this score against the benefit of the framework?

__mharrison__ 14y ago
Yes, the "excessive complexity" is a measure I've not heard of before. Surely summing up functions over 10 doesn't make sense.
crucialfelix 14y ago
it directly correlates to the number of hours you will spend with the debugger stepping through the labyrinth admin trying to figure out why your widget ended up without a whatsit.
- andybak 14y ago
  Isn't that dependent on actually hitting a bug in the framework where you need to do that?
  - freshhawk 14y ago
    Not necessarily a bug, more often it's just something not working the way you expect. Documentation is always ambiguous when you get down to the fine details and even in a very well documented project like Django there is still a whole lot of code surface area that is not documented other than an autogenerated API listing.
  - shabble 14y ago
    I recall reading somewhere that the distinction between a framework and a library was that in a library, you[r code] calls the functions it needs, whilst in a framework, it calls you. Often, bugs in your code will manifest as the framework throwing exceptions somewhere internally, often with difficult to interpret stack traces until you're familiar with how things work and what parts are safe to ignore. I've not had much success with interactive debugging in django (recommendations/howtos would be hugely appreciated), but I can imagine a similar situation in which you have to learn what is safe to skip through (and maybe how to automate that to break only at points of interest, especially those points which are in some internal django setup methods)
    - crucialfelix 14y ago
      Most of my most time consuming django hours involve forms or admin. it's not that there is a bug in my code, it's just very twisted and thick in there. Eg. Form classes are created dynamically per request and then instantiated. Lots of currying, many places that params can be specified.
      - mattdawson 14y ago
        A little off topic, but forms are a big PITA using Flask and extensions, too. Forms are definitely not a solved problem in the python world.
        irahul 14y ago
        What are you using? They are pretty convenient with WTForms. # models.py class Post(db.Model): id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String(80)) title = db.Column(db.String(200)) content = db.Column(db.Text) def __init__(self, name, title, content): self.name = name self.title = title self.content = content # forms.py import flaskext.wtf as wtf from flaskext.wtf import Form, validators from wtforms.ext.sqlalchemy.orm import model_form import models PostForm = model_form(models.Post, Form, field_args = { 'name': {'validators': [validators.required()]}, 'title': {'validators': [validators.required(), validators.length(min=5)]}, }) # views.py def post_new(): form = forms.PostForm() if form.validate_on_submit(): post = models.Post(form.name.data, form.title.data, form.content.data) db.session.add(post) db.session.commit() return redirect(url_for('post.index')) return render_template('post/new.slim', form=form) # _post_form.slim - from 'helpers.slim' import render_field form method="POST" class="well" = form.hidden_tag() = render_field(form.name, class\="span4") = render_field(form.title, class\="span4") = render_field(form.content, class\="span4") .field input type="submit" class="btn btn-success" # post/new.slim - extends 'layout.slim' - block content .span6 h2 Creating new post - include 'post/_post_form.slim' a href="=url_for('.index')" class="btn btn-primary btn-small" Back # helpers.slim - macro render_field(field) div class="{{ 'field-with-errors' if field.errors else 'field' }}" - if field.errors - for error in field.errors p class="error" = error = field.label = (field(**kwargs) | safe) Don't bother about the slim templates. It's a small jinja2 extension which I use to give me slim syntax. Now this probably looks like a lot. But consider that you write the helper to render the form only once. Also, you can write a helper to generate models and form scaffolding for you. That's what I do. python manage.py create_model post -f 'name:String(80) title:String(200) content:Text' It generates me the model, form and form template(models.py, forms.py, _post_form.py). The form of course will have empty validators which I fill.
freshhawk 14y ago
The other frameworks would "fall down" or you would need to write a small amount of glue code? While Django is mature, I'm using it right now in fact, I find that I spend a hell of a lot of time trying to figure out why Django is doing a specific thing or how to convince it to do the exact thing I want. I'm convinced, after a few years of Django work and a year or so of Flask (or just werkzeug libraries), that Django is the wrong level of complexity for a web framework. For every minute I've saved by having django handle the edge case or having some great feature built in I feel like I've lost a few minutes to fighting against the framework when my use case doesn't fit into the expected usage and I'm fighting against a fairly rigid framework. This feeling is what I think the OP is trying to get at with the "excessive complexity" measurement, although using a single metric like this is probably not the answer. It does fit decently well with my impressions of the frameworks listed (among the ones I've used anyway) but this is a messy and subjective problem. I've found myself firmly in the "libraries > frameworks" camp because of this issue so I'm certainly biased towards liking this metric, even with it's faults.
- crucialfelix 14y ago
  Same here. I tried valiantly to do some class based views the other day and my spidey sense started going off. Maybe I'll find time later to get those the way I want them but I suspect they will suck up more time than they will save. It's a general problem with hierarchies of inheritance. Too many separate places where the actual functionality is, so you have to learn all of them and hold them in your head to understand the few pithy lines of code in front of you. And that's the issue with the admin and forms. Hard to keep track
  - camus 14y ago
    > It's a general problem with hierarchies of inheritance. And what do you suggest to make it easier for you to read, spaghetti code ? Django makes great use of mixins, mixins you can re-use to make your own views if you dont like the default generic views.
    - crucialfelix 14y ago

__mharrison__ 14y ago

Yes, the "excessive complexity" is a measure I've not heard of before. Surely summing up functions over 10 doesn't make sense.

crucialfelix 14y ago

it directly correlates to the number of hours you will spend with the debugger stepping through the labyrinth admin trying to figure out why your widget ended up without a whatsit.

andybak 14y ago
Isn't that dependent on actually hitting a bug in the framework where you need to do that?
- freshhawk 14y ago
  Not necessarily a bug, more often it's just something not working the way you expect. Documentation is always ambiguous when you get down to the fine details and even in a very well documented project like Django there is still a whole lot of code surface area that is not documented other than an autogenerated API listing.
- shabble 14y ago
  I recall reading somewhere that the distinction between a framework and a library was that in a library, you[r code] calls the functions it needs, whilst in a framework, it calls you. Often, bugs in your code will manifest as the framework throwing exceptions somewhere internally, often with difficult to interpret stack traces until you're familiar with how things work and what parts are safe to ignore. I've not had much success with interactive debugging in django (recommendations/howtos would be hugely appreciated), but I can imagine a similar situation in which you have to learn what is safe to skip through (and maybe how to automate that to break only at points of interest, especially those points which are in some internal django setup methods)
  - crucialfelix 14y ago
    Most of my most time consuming django hours involve forms or admin. it's not that there is a bug in my code, it's just very twisted and thick in there. Eg. Form classes are created dynamically per request and then instantiated. Lots of currying, many places that params can be specified.
    - mattdawson 14y ago
      A little off topic, but forms are a big PITA using Flask and extensions, too. Forms are definitely not a solved problem in the python world.
      - irahul 14y ago
        What are you using? They are pretty convenient with WTForms. # models.py class Post(db.Model): id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String(80)) title = db.Column(db.String(200)) content = db.Column(db.Text) def __init__(self, name, title, content): self.name = name self.title = title self.content = content # forms.py import flaskext.wtf as wtf from flaskext.wtf import Form, validators from wtforms.ext.sqlalchemy.orm import model_form import models PostForm = model_form(models.Post, Form, field_args = { 'name': {'validators': [validators.required()]}, 'title': {'validators': [validators.required(), validators.length(min=5)]}, }) # views.py def post_new(): form = forms.PostForm() if form.validate_on_submit(): post = models.Post(form.name.data, form.title.data, form.content.data) db.session.add(post) db.session.commit() return redirect(url_for('post.index')) return render_template('post/new.slim', form=form) # _post_form.slim - from 'helpers.slim' import render_field form method="POST" class="well" = form.hidden_tag() = render_field(form.name, class\="span4") = render_field(form.title, class\="span4") = render_field(form.content, class\="span4") .field input type="submit" class="btn btn-success" # post/new.slim - extends 'layout.slim' - block content .span6 h2 Creating new post - include 'post/_post_form.slim' a href="=url_for('.index')" class="btn btn-primary btn-small" Back # helpers.slim - macro render_field(field) div class="{{ 'field-with-errors' if field.errors else 'field' }}" - if field.errors - for error in field.errors p class="error" = error = field.label = (field(**kwargs) | safe) Don't bother about the slim templates. It's a small jinja2 extension which I use to give me slim syntax. Now this probably looks like a lot. But consider that you write the helper to render the form only once. Also, you can write a helper to generate models and form scaffolding for you. That's what I do. python manage.py create_model post -f 'name:String(80) title:String(200) content:Text' It generates me the model, form and form template(models.py, forms.py, _post_form.py). The form of course will have empty validators which I fill.

freshhawk 14y ago

The other frameworks would "fall down" or you would need to write a small amount of glue code? While Django is mature, I'm using it right now in fact, I find that I spend a hell of a lot of time trying to figure out why Django is doing a specific thing or how to convince it to do the exact thing I want. I'm convinced, after a few years of Django work and a year or so of Flask (or just werkzeug libraries), that Django is the wrong level of complexity for a web framework. For every minute I've saved by having django handle the edge case or having some great feature built in I feel like I've lost a few minutes to fighting against the framework when my use case doesn't fit into the expected usage and I'm fighting against a fairly rigid framework. This feeling is what I think the OP is trying to get at with the "excessive complexity" measurement, although using a single metric like this is probably not the answer. It does fit decently well with my impressions of the frameworks listed (among the ones I've used anyway) but this is a messy and subjective problem. I've found myself firmly in the "libraries > frameworks" camp because of this issue so I'm certainly biased towards liking this metric, even with it's faults.

crucialfelix 14y ago
Same here. I tried valiantly to do some class based views the other day and my spidey sense started going off. Maybe I'll find time later to get those the way I want them but I suspect they will suck up more time than they will save. It's a general problem with hierarchies of inheritance. Too many separate places where the actual functionality is, so you have to learn all of them and hold them in your head to understand the few pithy lines of code in front of you. And that's the issue with the admin and forms. Hard to keep track
- camus 14y ago
  > It's a general problem with hierarchies of inheritance. And what do you suggest to make it easier for you to read, spaghetti code ? Django makes great use of mixins, mixins you can re-use to make your own views if you dont like the default generic views.
  - crucialfelix 14y ago