8 ms·

Back in the Django saddle

212 points by slig 15y ago

kenneth_reitz 15y ago
Really excited about the move to GitHub!
jphackworth 15y ago
It's great to hear that Django is moving to GitHub. It seems like the Python community has been slow to adopt git, perhaps because Bazaar and Mercurial are written in Python, and perhaps because GitHub uses Ruby. That said, it seems like git is emerging as the winner, and IMHO GitHub is far superior to anything available outside of git, so I'm glad they're making the move.
- sc68cal 15y ago
  Indeed, this is good news - there have always been a pull request or two on the Django GitHub mirror that would need to be closed and redirected to the Django project bug tracker, where they would need to generate a patch. This always slowed contributions and made people who genuinely wanted to help jump through needless hoops.
- zalew 15y ago
  heh, I myself started using HG partly because of language patriotism, partly because Bitbucket (running on Django) had a better offer than Github. yet one had to be out of his mind not to like Django moving to any of those providers. it's a great step. (a little tiny bit sad they didn't choose hg/bitbucket ;)) the move surprised me a bit, AFAIR when this topic (moving to a DVCS) was raised on DjangoCons, Russel explained that's not a priority (correct me if my memory fails).
  - eli 15y ago
    I don't want to put words in his mouth, but I would imagine Adrian's list of priorities represents just that -- the things he wants to work on.
    - adrianh 15y ago
      Yes, that, plus the things that I think would be good for the framework and the community.
      - zalew 15y ago
        oh, great :) forgot to link the hn post in comments on your blog, glad you came here so fast. cheerz
- briancurtin 15y ago
  > It seems like the Python community has been slow to adopt git, perhaps because Bazaar and Mercurial are written in Python, and perhaps because GitHub uses Ruby. For a lot of people in the Python world, choosing a DVCS just means picking what CPython picked (hg). At the time, that decision was at least partly due to the fact that git had poor Windows support, and less about the languages involved (GitHub/Ruby weren't a factor anyway since it would be a self-hosted git install). If the decision was to be made again today, most people I've talked to think git would be the choice.
  - glenjamin 15y ago
    My experience is still that git is at best a second class citizen on windows, in terms of installation, performance and usability. Is this no longer the case in some way?
    - deleted 15y ago
      [deleted]
    - roryokane 15y ago
      I have used Git on only Windows and Mac, and these are my experiences: Installation on Windows is easy – just use msysGit[1]. I don’t know about performance because I never worked with large repositories. For usability, all the command-line options and tools work as normal, and git gui is equally usable/unusable as it is on Mac. Mac does have a wider selection of GUI front-ends for Git, including my favorite, Tower, but Windows does have a few, including SmartGit, which is enough for simple usage. Windows’ command line program is harder to use than Mac’s Terminal, but the free program Console[2] gives it most features I need. [1] http://code.google.com/p/msysgit/ http://code.google.com/p/msysgit/ [2] http://sourceforge.net/projects/console/ http://sourceforge.net/projects/console/
    - zheng 15y ago
      I can't really speak to performance (I don't have any large projects where I could tell a difference), but the install is painless, and the windows git shell is really nice.
    - 15y ago
frankwiles 15y ago
Welcome back Adrian!
maxklein 15y ago
This is why Django is so slow moving. People are not really spending time developing it. Thank goodness there is Bottle.py and Flask now.
- kgrin 15y ago
  Not that it couldn't move faster, and I'm all for more Python web frameworks, but Django has certainly made significant progress. I suspect most people (that is, developers who use the framework but don't necessarily contribute to it) probably couldn't tell that a BDFL has basically been MIA - it doesn't feel like development's stopped altogether (although again, yes, it can obviously be sped up, everyone's got their own pet features, etc.)
- arctangent 15y ago
  Django and Flask aim to solve different types of problem.
  - jokull 15y ago
    I would argue that's not quite the case. So if they solve different problems you could hypothetically use them in the same projects? Possible, but hardly the case in real world scenarios.
    - arctangent 15y ago
      You could certainly use Django or Flask to implement the same functionality, but I was trying to use the word "problem" in a wider sense than that. In my real word scenarios I'm often faced with requirements of vastly different scale and highly variable deadlines. I also have to consider the likelihood of the code being added to in the future - potentially by someone else on my team who is less experienced by me. All these things taken together - and more - constitute what I am calling a "problem". My Django apps all run to thousands of lines of code and are well documented and thoroughly tested. It's fairly routine for the lifecycle of these apps to stretch over years, with an ongoing requirement for maintenance and new features. If I need to create a social network for my company which ties into their existing information sources, then Django is where I start. On the other hand, my Flask apps tend to run to the small hundreds of lines of code. They're usually hacked together quickly for a very specific use case and there's very little in the way of documentation. They might not even work correctly except in fairly limited circumstances (e.g. no time to write form validation code) and might get thrown away after being used a small number of times. If I need to create a tool to allow users to purge parts of our Varnish cache then Flask is where I start. Perhaps not everybody uses the two frameworks in quite the same way, but I find that they complement each other well.
cavilling_elite 15y ago
Welcome back, I am really interested to hear what "changes were made to the framework that [Adrian] would've prevented had [he] been more involved."
cookiecaper 15y ago
I've tried several times but I just can't bring myself to enjoy using Django. I am a Pyramid/Pylons guy all the way.
kmfrk 15y ago
I am most interested to see what the transition from SHA1 to PBKDF2[1][2] will mean for Django. I have wanted to just switch to bcrypt, but it's such a pain in the ass to manage on Windows and will probably break for users testing my projects locally. It's not like SHA1 is tantamount to leaving the barn door open, but it doesn't sit well with me to stick with it, until it is replaced natively. [1]: http://comments.gmane.org/gmane.comp.python.django.devel/33205 http://comments.gmane.org/gmane.comp.python.django.devel/332... [2]: https://code.djangoproject.com/ticket/15367 https://code.djangoproject.com/ticket/15367
- rglullis 15y ago
  What is wrong with https://bitbucket.org/dwaiter/django-bcrypt/ https://bitbucket.org/dwaiter/django-bcrypt/ ? At least on Linux, I installed it and had no issue whatsoever.
  - po 15y ago
    There's nothing wrong with django-bcrypt. The main reason for picking PBKDF2 is because it can be implemented without pulling in a dependency to the core framework. The Django team does a lot of work to maintain backwards-compatability and smooth upgrades which is why having this in core is important to me.
  - RyanMcGreal 15y ago
    Python (and Django) prides itself on being cross-platform. Installing bcrypt on Windows is a huge PITA.
    - koen 15y ago
      But bcrypt is just a few files of portable C (the .S is optional) with no dependencies whatsoever ?
reinhardt 15y ago
"... and changes were made to the framework that I would've prevented had I been more involved." Such as?
reinhardt 15y ago
"... and changes were made to the framework that I would've prevented had I been more involved." Such as?
LeafStorm 15y ago
One thing that I think the Django core team needs to work on is documenting best practices. And I know that there are a bunch of different huge companies who build things in Django and all have different standards for how to develop and deploy, but just running $ django-admin.py startproject PROJECT $ cd PROJECT $ python manage.py startapp is simply not cutting it.
- philipkimmey 15y ago
  I totally agree - having no standards around common problems (like how to deal with tests once they get too big for a single tests.py) is extremely inconvenient.
  - nicpottier 15y ago
    I thought the general solution to this was just to create a /tests directory and stuff everything in there, broken out as you wish? Did I just make that up?
    - 2mur 15y ago
      No that's basically how everyone does it. Same thing for models, views, etc. It's all python.
  - bad_user 15y ago
    That's because Django, while monolithic, is in many ways based on pythonic principles. In Ruby, for instance, you really need conventions as in Ruby the concept of packages and how they get included / used is a lot more relaxed. In Python tests.py is a package as far as Python is concerned. If it gets too big you can make it a directory and break its contents in several sub-packages. I did this with everything else too, like views.py or models.py The one concept Django has that I consider a flaw is in fact non-pythonic - apps. That's because apps are not just simple packages. Instead apps are packages that have to be specified in an INSTALLED_APPS constant in a top-level "settings" package. This makes using parts of Django in scripts a PITA, as your script needs an accompanying settings file. Also, apps are not properly defined either and in some instances an app must have a "models" subpackage (or at least this used to be the case).
capkutay 15y ago
I'm curious to see if any improvements to GeoDjango will be made in the near future...trying to decide if django is the right tool for an app with GIS capabilities.
SammyRulez 15y ago
Good to hear that "this week in django" will be back.. but the podcast edition would be a great plus for the community.
- minikomi 15y ago
  Though not a Django user, I immediately wished this existed for a number of other frameworks/projects. What a great idea to keep people interested in the project.
tocomment 15y ago
What are the best practices for testing in Django? I feel silly testing my models. And testing my views also seems kind of awkward. But then there's nothing else to test. Any advice?
- numix 15y ago
  This really depends on your situation. If you are writing a reusable app, then you probably want both unit tests and a sample project to run integration tests against. For testing a basic website, you'll probably want to test any custom managers or model methods, and your views. A good guide to getting started is here: http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/ http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-... For full-stack tests, you can use something like Splinter (http://splinter.cobrateam.info/ http://splinter.cobrateam.info/).

212 points by slig 15y ago

Really excited about the move to GitHub!

It's great to hear that Django is moving to GitHub. It seems like the Python community has been slow to adopt git, perhaps because Bazaar and Mercurial are written in Python, and perhaps because GitHub uses Ruby. That said, it seems like git is emerging as the winner, and IMHO GitHub is far superior to anything available outside of git, so I'm glad they're making the move.

sc68cal 15y ago
Indeed, this is good news - there have always been a pull request or two on the Django GitHub mirror that would need to be closed and redirected to the Django project bug tracker, where they would need to generate a patch. This always slowed contributions and made people who genuinely wanted to help jump through needless hoops.
zalew 15y ago
heh, I myself started using HG partly because of language patriotism, partly because Bitbucket (running on Django) had a better offer than Github. yet one had to be out of his mind not to like Django moving to any of those providers. it's a great step. (a little tiny bit sad they didn't choose hg/bitbucket ;)) the move surprised me a bit, AFAIR when this topic (moving to a DVCS) was raised on DjangoCons, Russel explained that's not a priority (correct me if my memory fails).
- eli 15y ago
  I don't want to put words in his mouth, but I would imagine Adrian's list of priorities represents just that -- the things he wants to work on.
  - adrianh 15y ago
    Yes, that, plus the things that I think would be good for the framework and the community.
    - zalew 15y ago
      oh, great :) forgot to link the hn post in comments on your blog, glad you came here so fast. cheerz
briancurtin 15y ago
> It seems like the Python community has been slow to adopt git, perhaps because Bazaar and Mercurial are written in Python, and perhaps because GitHub uses Ruby. For a lot of people in the Python world, choosing a DVCS just means picking what CPython picked (hg). At the time, that decision was at least partly due to the fact that git had poor Windows support, and less about the languages involved (GitHub/Ruby weren't a factor anyway since it would be a self-hosted git install). If the decision was to be made again today, most people I've talked to think git would be the choice.
- glenjamin 15y ago
  My experience is still that git is at best a second class citizen on windows, in terms of installation, performance and usability. Is this no longer the case in some way?
  - deleted 15y ago
    [deleted]
  - roryokane 15y ago
    I have used Git on only Windows and Mac, and these are my experiences: Installation on Windows is easy – just use msysGit[1]. I don’t know about performance because I never worked with large repositories. For usability, all the command-line options and tools work as normal, and git gui is equally usable/unusable as it is on Mac. Mac does have a wider selection of GUI front-ends for Git, including my favorite, Tower, but Windows does have a few, including SmartGit, which is enough for simple usage. Windows’ command line program is harder to use than Mac’s Terminal, but the free program Console[2] gives it most features I need. [1] http://code.google.com/p/msysgit/ http://code.google.com/p/msysgit/ [2] http://sourceforge.net/projects/console/ http://sourceforge.net/projects/console/
  - zheng 15y ago
    I can't really speak to performance (I don't have any large projects where I could tell a difference), but the install is painless, and the windows git shell is really nice.
  - 15y ago

frankwiles 15y ago

Welcome back Adrian!

maxklein 15y ago

This is why Django is so slow moving. People are not really spending time developing it. Thank goodness there is Bottle.py and Flask now.

kgrin 15y ago
Not that it couldn't move faster, and I'm all for more Python web frameworks, but Django has certainly made significant progress. I suspect most people (that is, developers who use the framework but don't necessarily contribute to it) probably couldn't tell that a BDFL has basically been MIA - it doesn't feel like development's stopped altogether (although again, yes, it can obviously be sped up, everyone's got their own pet features, etc.)
arctangent 15y ago
Django and Flask aim to solve different types of problem.
- jokull 15y ago
  I would argue that's not quite the case. So if they solve different problems you could hypothetically use them in the same projects? Possible, but hardly the case in real world scenarios.
  - arctangent 15y ago
    You could certainly use Django or Flask to implement the same functionality, but I was trying to use the word "problem" in a wider sense than that. In my real word scenarios I'm often faced with requirements of vastly different scale and highly variable deadlines. I also have to consider the likelihood of the code being added to in the future - potentially by someone else on my team who is less experienced by me. All these things taken together - and more - constitute what I am calling a "problem". My Django apps all run to thousands of lines of code and are well documented and thoroughly tested. It's fairly routine for the lifecycle of these apps to stretch over years, with an ongoing requirement for maintenance and new features. If I need to create a social network for my company which ties into their existing information sources, then Django is where I start. On the other hand, my Flask apps tend to run to the small hundreds of lines of code. They're usually hacked together quickly for a very specific use case and there's very little in the way of documentation. They might not even work correctly except in fairly limited circumstances (e.g. no time to write form validation code) and might get thrown away after being used a small number of times. If I need to create a tool to allow users to purge parts of our Varnish cache then Flask is where I start. Perhaps not everybody uses the two frameworks in quite the same way, but I find that they complement each other well.

cavilling_elite 15y ago

Welcome back, I am really interested to hear what "changes were made to the framework that [Adrian] would've prevented had [he] been more involved."

cookiecaper 15y ago

I've tried several times but I just can't bring myself to enjoy using Django. I am a Pyramid/Pylons guy all the way.

kmfrk 15y ago

I am most interested to see what the transition from SHA1 to PBKDF2[1][2] will mean for Django. I have wanted to just switch to bcrypt, but it's such a pain in the ass to manage on Windows and will probably break for users testing my projects locally. It's not like SHA1 is tantamount to leaving the barn door open, but it doesn't sit well with me to stick with it, until it is replaced natively. [1]: http://comments.gmane.org/gmane.comp.python.django.devel/33205 http://comments.gmane.org/gmane.comp.python.django.devel/332... [2]: https://code.djangoproject.com/ticket/15367 https://code.djangoproject.com/ticket/15367

rglullis 15y ago
What is wrong with https://bitbucket.org/dwaiter/django-bcrypt/ https://bitbucket.org/dwaiter/django-bcrypt/ ? At least on Linux, I installed it and had no issue whatsoever.
- po 15y ago
  There's nothing wrong with django-bcrypt. The main reason for picking PBKDF2 is because it can be implemented without pulling in a dependency to the core framework. The Django team does a lot of work to maintain backwards-compatability and smooth upgrades which is why having this in core is important to me.
- RyanMcGreal 15y ago
  Python (and Django) prides itself on being cross-platform. Installing bcrypt on Windows is a huge PITA.
  - koen 15y ago
    But bcrypt is just a few files of portable C (the .S is optional) with no dependencies whatsoever ?

reinhardt 15y ago

"... and changes were made to the framework that I would've prevented had I been more involved." Such as?

reinhardt 15y ago

"... and changes were made to the framework that I would've prevented had I been more involved." Such as?

LeafStorm 15y ago

One thing that I think the Django core team needs to work on is documenting best practices. And I know that there are a bunch of different huge companies who build things in Django and all have different standards for how to develop and deploy, but just running $ django-admin.py startproject PROJECT $ cd PROJECT $ python manage.py startapp is simply not cutting it.

philipkimmey 15y ago
I totally agree - having no standards around common problems (like how to deal with tests once they get too big for a single tests.py) is extremely inconvenient.
- nicpottier 15y ago
  I thought the general solution to this was just to create a /tests directory and stuff everything in there, broken out as you wish? Did I just make that up?
  - 2mur 15y ago
    No that's basically how everyone does it. Same thing for models, views, etc. It's all python.
- bad_user 15y ago
  That's because Django, while monolithic, is in many ways based on pythonic principles. In Ruby, for instance, you really need conventions as in Ruby the concept of packages and how they get included / used is a lot more relaxed. In Python tests.py is a package as far as Python is concerned. If it gets too big you can make it a directory and break its contents in several sub-packages. I did this with everything else too, like views.py or models.py The one concept Django has that I consider a flaw is in fact non-pythonic - apps. That's because apps are not just simple packages. Instead apps are packages that have to be specified in an INSTALLED_APPS constant in a top-level "settings" package. This makes using parts of Django in scripts a PITA, as your script needs an accompanying settings file. Also, apps are not properly defined either and in some instances an app must have a "models" subpackage (or at least this used to be the case).

capkutay 15y ago

I'm curious to see if any improvements to GeoDjango will be made in the near future...trying to decide if django is the right tool for an app with GIS capabilities.

SammyRulez 15y ago

Good to hear that "this week in django" will be back.. but the podcast edition would be a great plus for the community.

minikomi 15y ago
Though not a Django user, I immediately wished this existed for a number of other frameworks/projects. What a great idea to keep people interested in the project.

tocomment 15y ago

What are the best practices for testing in Django? I feel silly testing my models. And testing my views also seems kind of awkward. But then there's nothing else to test. Any advice?

numix 15y ago
This really depends on your situation. If you are writing a reusable app, then you probably want both unit tests and a sample project to run integration tests against. For testing a basic website, you'll probably want to test any custom managers or model methods, and your views. A good guide to getting started is here: http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/ http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-... For full-stack tests, you can use something like Splinter (http://splinter.cobrateam.info/ http://splinter.cobrateam.info/).