77 karma · joined May 7, 2012
You're just arguing like a 10 year old fan boy now. Django is great for sites I love it. I also use other tools when I need different things. As for reinventing the wheel it's a very simple code snippet taken from a reliable source then changed to fit needs. So go home sleep learn new things... Don't attempt to build the next OS in Django.
> Not really. You're always free to use raw SQL, and it makes it pretty convenient to do so for the occasions when what you want exceeds the ORM's capabilities (which will likely happen).
I can't argue with this, fine.
> Stuff like a rate limiter, for instance, or a pluggable social media authentication backend. Or the one mentioned by the OP. All useful when making APIs.
Rate limiter is framework independent, can be built using Redis with a few lines of code. So not applicable.
Pluggable social media authentication backend is for websites not APIs for APIs you most commonly use API key/secret. for an api you can still build your portal in Django and do all authentication/whatever there and simply sign requests for the API.
> You're not railroaded into using any of those things if you don't want to (the same way you are with RoR). All of them are optional and most of them are even swappable without too much effort.
I am familiar with Django, and I know that you can (not the ORM though), but do you want to drive a monster truck when all you need is a car to get around? You could, you will get odd looks though.
Since you can't use Django's ORM anywhere else you need to use something that another "car" supports.
I'll leave you with: "if all you have is a hammer everything looks like a nail"
Well those are most of the comparisons that could be made, from the top of my head I can't think of any other features that the two share.
> Too many junior developers make the mistake of thinking that their problem, project or app is somehow a unique snowflake and end up reinventing the wheel because they had no idea the wheel existed. Semi-experienced developers will still make this mistake by making bad architectural decisions in the name of flexibility or performance that end up locking them out of library ecosystems that means they are forced to reinvent the wheel even when they know it exists.
Doesn't sticking with Django lock you into the ORM and it's capabilities itself? Unless the library you're using is a Django extension you have the same pool of libraries available to you, so that's an invalid point.
> It's a myth that Django is heavy weight.
I saw that blog post too, however by heavy weight I meant all the remaining stuff you don't need for an API, e.g. you don't need the template, view, form, ... layers
Again my argument is based on building an API not a Website.
For the Django part of your comment the other modules it provides are useful for building a website but not an API which was in the root comment. Indeed for a website Django is my preferred tool too. Although in a project where I know the API is the core I would choose something lighter weight (using flask in my current project but learning from comments here Pyramid is something to look into too) and then build the portal in Django, handle user authentication there and allow access to the authenticated users to the API via requests signed in Django or direct access via API keys. In my experience it's the fastest/most flexible approach in terms of dev.
Edit: The overhead thing was a secondary point my main point was handling data.
print " is in the lyrics \n".join([set(lyrics_list) & set(words)]), "is in the lyrics" # Do this
lyrics_set = set(lyrics_list) # Linear time set construction
words = make_wordlist()
for word in words:
if word in lyrics_set: # Constant time
print word, "is in the lyrics"
lyrics_set = set(lyrics_list)
words = set(make_wordlist())
matched_words = list(lyrics_set & words)
for word in matched_words:
print word, "is in the lyrics"A more appropriate title could be "list of must read articles for modern web development".