61–70 of 195 posts
Before Django the gold standard for Python web apps was Zope. What a tremendous achievement by the Django team!
Before Django the gold standard for Python web apps was Zope. What a tremendous achievement by the Django team!
Not sure if a lot of people on HN are old enough to remember that :)
For what it's worth, I definitely remember Zope.
Earlier quoted context omitted.
There’s nothing wrong with PHP. And Laravel is very popular for good reasons. There are people out there writing Python just as bad as what you think of as bad PHP. One dev I knew insisted everything must be a list comprehension — including all for loops in regular flow control. That was Not Good(tm). ——— Edit: please read the parent comments for context. GP said there’s no right or wrong and OP said then why not use…
I generally agree philosophically but PHP has a couple of features which make problems more likely: the C style error handling increases the odds of problems being ignored (yes, Python can have except:pass but that’s more obvious & requires intent) and the mushy typing hits even experienced developers who didn’t think about whether they needed === instead of ==. The standard library’s inconsistent parameter ordering…
Been a long time since our chats at DC Python. Hope you’ve been doing well, sir!
Django is the gold standard for consistently pushing out reliable, well documented open source software without any marketing fluff or other bs. The amount of value the team is adding to the world can't be overstated.
I'm more if a flask man myself. Worked with django only when I had to. Maybe I'm wrong?
I'm more if a flask man myself. Worked with django only when I had to. Maybe I'm wrong?
Django has a few drawbacks: 1. It’s tricky to use in non-web contexts. If you ever need something to happen as a response to an event which is not a web request, Django makes this difficult and ugly. 2. Django also more or less requires ownership of the database in order to function as intended. If you want to have your Django objects in your own database and handle schema changes centrally (to, for example, alleviat…
But maybe I'm misunderstanding the kind of task you have in mind?
For (2) - you seem to be saying "if you don't want Django to handle migrations then you lose the benefit of Django handling migrations" - but again I might have missed some subtlety here?
I'm more if a flask man myself. Worked with django only when I had to. Maybe I'm wrong?
Django has a few drawbacks: 1. It’s tricky to use in non-web contexts. If you ever need something to happen as a response to an event which is not a web request, Django makes this difficult and ugly. 2. Django also more or less requires ownership of the database in order to function as intended. If you want to have your Django objects in your own database and handle schema changes centrally (to, for example, alleviat…
Django is the gold standard for consistently pushing out reliable, well documented open source software without any marketing fluff or other bs. The amount of value the team is adding to the world can't be overstated.
A couple of years ago(2014) I made my first Python website and really enjoyed, however when it was time to put it onlin I quickly discovered that setting up hosting and configuring it was as large a task in getting to know pip, env, unicorn, apache2 and a plethora of other software to host it, is this still the case? Becaue this is what keeps me of hosting websites with python.
Earlier quoted context omitted.
Depends what you want to do, and why you're doing it. Very often when I make something in Flask, I end up with so many dependencies it might as well be Django (but without the cohesion). On the other hand, Django might be overkill in some situations (e.g. a small API without a relational database backend).
I was forced to fall on this trap once: a guy has a small Flask app up and running, and he asked for help to implement: an ORM with migrations, an Admin and form validation (among other things that had nothing to do with Django such file parsing). I suggested to migrate the app from Flask to Django while it was small and simple, but he refused for Django is "too big and complicated". OK, then. We ended up creating a…
"Any sufficiently complicated Flask app contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Django"