

Back in the Django saddle - slig
http://www.holovaty.com/writing/back-to-django/

======
jphackworth
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.

~~~
briancurtin
> 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
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?

~~~
zheng
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.

------
kmfrk
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/332...](http://comments.gmane.org/gmane.comp.python.django.devel/33205)

[2]: <https://code.djangoproject.com/ticket/15367>

~~~
rglullis
What is wrong with <https://bitbucket.org/dwaiter/django-bcrypt/> ?

At least on Linux, I installed it and had no issue whatsoever.

~~~
RyanMcGreal
Python (and Django) prides itself on being cross-platform. Installing bcrypt
on Windows is a _huge_ PITA.

~~~
koen
But bcrypt is just a few files of portable C (the .S is optional) with no
dependencies whatsoever ?

------
LeafStorm
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
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
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
No that's basically how everyone does it. Same thing for models, views, etc.
It's all python.

------
cavilling_elite
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."

------
kenneth_reitz
Really excited about the move to GitHub!

------
reinhardt
"... and changes were made to the framework that I would've prevented had I
been more involved."

Such as?

------
tocomment
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
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-...](http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/)

For full-stack tests, you can use something like Splinter
(<http://splinter.cobrateam.info/>).

------
capkutay
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.

------
frankwiles
Welcome back Adrian!

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

~~~
minikomi
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.

------
cookiecaper
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.

------
maxklein
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.

~~~
arctangent
Django and Flask aim to solve different types of problem.

~~~
jokull
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
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.

~~~
jokull
That's interesting. Now that you mention it, I've noticed my Flask apps run a
much tighter LOC count. I always assumed that was because I was achieving the
same solution but in a simpler way. In any case, I __migrated __to Flask
because I'm much happier coding in it. My admin apps are blueprint css + some
really simple views that take as much effort to write as I would be spending
tweaking the Admin classes in Django. Maybe it's time to have a look at Django
again, now that Holovaty is making a comeback eah? hehe.

