Sounds to me like this guy was using the wrong tool for the job.
Why Django Sucks
121–130 of 206 posts
Re: Why Django Sucks
#122Earlier quoted context omitted.
But now you have an auth system that's tightly coupled to SQLAlchemy. How is that different from the regular system, other than you're using SQLAlchemy rather than Django's ORM? I'm also finding it hard to think of a use case where you need to authenticate 100 users at once, so your initial rationale (100 separate updates) doesn't really work. Surely you'd use a different tool to populate your database, but Django's…
Pyramid has an auth system not tied to any ORM or persistence system whatsoever: http://pyramid.readthedocs.org/en/latest/tutorials/wiki/auth... I'd say that's better than anything hardcoded to a fixed database schema. There's a whole world of development that has no interest in using a mediocre, off the shelf database schema in lieu of one that is designed exactly for the problem at hand.
Er, that looks pretty hideous to me.
I guess the idea is that Pyramid exposes a lot of the internals so that you can tweak it, but what's going on in that code is completely lost in the noise. From all of the hits that I can see on Stack Overflow, I'm not the only one who finds it hard to understand.
Not to mention that it completely punts on adding any sort of persistence for user models or password hashing. I stopped trying to figure out what was going on when I realised that
headers = remember(request, login)
Compare to Django's login, which is a lot clearer, even though it includes all of the things that the Pyramid version skips over: https://docs.djangoproject.com/en/dev/topics/auth/#django.co...
Re: Why Django Sucks
#123Earlier quoted context omitted.
Heh. Who needs python manage.py syncdb when you can write a function: from contextlib import closing def init_db(): with closing(connect_db()) as db: with app.open_resource('schema.sql') as f: db.cursor().executescript(f.read()) db.commit()
Who needs a one-line schema migration command that can be rolled back when you can just copypaste boilerplate which doesn't do anything nearly as useful or sophisticated and requires you to go and actually write out the table definitions? You're right, dude. Great idea.
Whoops. Mind the sarchasm there ;)
Re: Why Django Sucks
#124Earlier quoted context omitted.
It's from Flask's recipe section: http://flask.pocoo.org/docs/patterns/sqlite3/#initial-schema... edit: not if you're using sqlite, since alembic doesn't seem to try too hard supporting it.
> not if you're using sqlite, since alembic doesn't seem to try too hard supporting it. Because its brand new, written by pretty much one person (I'll give you a hint, it's me), and also sqlite barely supports migrations itself ( http://sqlite.org/faq.html#q11 ). You're trolling pretty hard in this thread, maybe you should let other toolsets besides django have a chance.
I'm not "trolling", I just disagree with you.
And yes, I know you wrote it. You wrote SQLAlchemy too.
Re: Why Django Sucks
#125Earlier quoted context omitted.
The problem is not frameworks; the problem is object oriented programming. Simply put, OOP lends itself to kitchen-sink frameworks because it is the only way to really share code in OOP. We write these large hierarchy of objects and then, because we have to carefully maintain state, we mark most of it as private, or sealed. Then we give precise instructions on how to consume and use the code, and even more precise in…
Well that's strange because Django didn't use much OO either when I used it in the past, only for the ORM.
Also this is Python, so you can poke the internals however you like :)
Re: Why Django Sucks
#126Django is just badly designed. Many things in Django don't work right from the start, and changing them is a big, big pain. When I tried Django, I had to make some changes to the authentication (I can't remember well, but I think I wanted to be able to sign in with email addresses). It was a big pain that took quite a while, and made it incompatible with the rest.
In the end, as the application grew, I had to throw out most of Django and just use my own custom written code. Steep learning curve for a process that will be thrown out later anyways.
A micro-framework is much better. At least you can mix and match as you want.
Re: Why Django Sucks
#127Earlier quoted context omitted.
> not if you're using sqlite, since alembic doesn't seem to try too hard supporting it. Because its brand new, written by pretty much one person (I'll give you a hint, it's me), and also sqlite barely supports migrations itself ( http://sqlite.org/faq.html#q11 ). You're trolling pretty hard in this thread, maybe you should let other toolsets besides django have a chance.
Sorry, wait a second. You're comparing a feature built in to the core of django to something brand new that has a support team of one person and accusing the other guy of trolling? I'm sure your code is fine, but you can't possibly argue that it is on par with a major component of a major framework and be taken seriously.
You misread him. He's saying that it's unfair to compare alembic, written solely by him, to something built into Django and debugged by lots of people.
Which is fair enough IMO, but it's not really convincing me that Flask is a better way to go.
Re: Why Django Sucks
#128Earlier quoted context omitted.
Evidently you may be trapped inside yours -- I made no mention of VertexDB nor did I suggest any particular database. However, for example, Datomic ( http://www.infoq.com/presentations/The-Design-of-Datomic ) is interesting, which is distributed and uses Amazon's DynamoDB storage service.
I'm yet to see a Django based website that outgrows any old rdbms for auth . Care to back up your claim that it's bad? Same for admin . You do realize that Django's admin is just a search result of objects defined in its ORM, and that objects defined in its ORM are very obviously stored in an rdb - right? What would you like admin to use for managing data stored in an rdb? There's barely anything other than the model…
It looks like you're new here. Make sure you understand the context before you go trolling else you might be mistaken for a chatterbot with all the non sequiturs.
Re: Why Django Sucks
#129I'm not quite sure I understand slide 48 which talks about constraints. Does a text editor have more or less constraints than an IDE? I would argue that it has less constraints, however I assume he is arguing that text editors are better which implies that they have more constraints. The same goes for Pen&Paper vs digital notes. Surely being able to write in any direction at any size with any style as well as draw me…
I was at the talk, and the way he explained it was that the first column allows for less customization. Kenneth said that if he would use Linux he would spend all day tweaking it, and not getting work done. The same goes for pen & paper notes over digital notes, once they're written down, you're not tweaking them anymore. A simple text editor does not have all the fancy functions to play with that an IDE does. So he is indeed advocating the first column, with regards to them being tools that are not as configurable as the second column.
Re: Why Django Sucks
#130I use Django and Flask quite a bit. They are the first two things I go to for building a site. For a small site, usually without a database, I mostly use Flask. For a large site with all the common features like auth and such, I use Django. Yeah, it has its bad points, but that's ok. It's worth suffering through whatever those bad points are because it has one gigantic good point. You don't have to reinvent the wheel…
You can also have an AUTH library coded against an interface, a protocol - and then use it with may different frameworks. I am convinced that this can be made practical if you choose the interfaces carefully. I have actually coded an auth lib against the PSGI interface (in Perl it is an equivalent of WSGI) plus a few virtual functions to be implemented in subclasses as connection to the storage database: https://github.com/zby/Plack-Middleware-Auth-Form