171–180 of 257 posts
Nice. Anyone building fun stuff using Django these days?
Earlier quoted context omitted.
A lot of these are pretty inaccurate, at least for modern Django. 1. I'm pretty sure that's not true if I'm correctly interpreting what you mean...You can do things like `path('myapp/', include(myapp.urls))` 4. Custom User models are now very straightforward (and recommended for non-trivial projects since it's easier to start with a Custom model that defaults to the default model for all options then modify it later)…
>A lot of these are pretty inaccurate, at least for modern Django. I wish you state exactly which of them are inaccurate and why, I sincerely want to know and understand >1. I'm pretty sure that's not true...You can do things like `path('myapp/', include(myapp.urls))` so you suggest I create an "app" for every sub-route? every major and non major web framework except Django has a router where you can mount it to any…
The startup checks are protecting you from more subtle problems because if you switch to a custom model, you need to do a migration for your stored data. That's a one-time process which can be squashed as soon as you migrate the last server running the old code.
> so you suggest I rewrite my applications to DRF just to have JSON http request decoding?
DRF is a helpful tool which solves a number of common cases but it's not doing anything you can't do in standard Django: that could be as simple as json.loads(request.body) in the appropriate view or, more commonly, a decorator or class-based view which provides standardized error handling, etc.
The reason why the stock forms API doesn't do this by default is that it's designed to support the interface in the HTML standard, which defines a simple key-value interface which is much simpler than what can be expressed in JSON:
https://html.spec.whatwg.org/multipage/form-control-infrastr...
Once you're moving out of the realm of standard browser interfaces it's much harder to write a generic validation interface suitable for having in a standard library, especially since there are multiple competing ideas of what this should look like and most of them are easily installable from PyPI without the Django project having to support them.
Earlier quoted context omitted.
There was a mailing list discussion about building U2F into Django, and I agree that should get done. I don't know a ton about SSO, although I'm more skeptical about building it into Django only because there are many different ways you might want the business logic to work, so to me that suggests using a library for that might be more appropriate than having it built into the framework.
There's not even a good 3rd party library, I spent like a day testing all of them out and it's so cumbersome compared to what I had to do with Flask-Security and Flask-Dance.
Earlier quoted context omitted.
HN isn't a person, it's a distribution of millions of people. If you think of it as a statistical cloud, it won't seem so paradoxical (e.g. "bipolar"). I don't follow your reference to Nietzsche but if it's relevant here, the same point would surely apply to any group. I try not to lose too much sleep over problems with HN that stem from humans in general. It's hard enough to change the few things we can.
>HN isn't a person, it's a distribution of millions of people. is obvious. what is insidious is the ideology that is preached on almost every controversial thread that papers over that fact.
https://hn.algolia.com/?query=%22hostile%20media%20effect%22...
Earlier quoted context omitted.
I do wish Django REST Framework shipped with faster serializer code.
You can use Serpy for that, although it will require some hacking for de serialization (a previous client of mine had a custom-built solution that used Serpy for responses but plain Form classes for parsing requests, but that seemed fine and they were handling 3k/requests per second at peak time).
https://voidfiles.github.io/python-serialization-benchmark/
Disclaimer: The above is not my project
Nice. Anyone building fun stuff using Django these days?
Django is still by far the best web framework as far as I can tell. Every couple years I check what's out there for GoLang, Rust, Nodejs, and Swift, and it seems like it will be a decade or more before anything else comes even close. Even though a lot of people don't like Django's ORM, at least it does almost everything you would want to do with Postgres. (And if you want more you can always use SqlAlchemy.) Most of…
Node.JS, on one-hand seems to take the approach of Go-lang - standard libraries that do basic web-handling well, but on the other hand, I think it is tarnished by Javascript's reputation for having too many third-party packages, too many options, new framework every week, etc.
C# / .NET core seems to be a strong up-and-comer alternative for teams looking for a full-featured and well-supported application framework with more type safety and performance than Python/Django or RoR. Elixir / Phoenix, as well, but that caters to an entirely different crowd.
I expect most Go users are not using much in the way of frameworks.
I've been away from Django for a few years, and hope to come back one day. One thing I'm curious about, coming from well-typed JS codebases using Flow, is the quality of typings in major projects like Django, Pandas, etc. Are their APIs well-typed? Can I get quality types for my models?
If you mean the object itself, then Python is strongly typed and will throw an error if you try to run the wrong method or access the wrong property on an object (although it will let you assign new ones, and it will let you add new columns to DataFrames of any data type, because that's very useful).
If you mean in the method or function calls, then often a parameter will allow different types because you might want to pass in the column name, a list of columns, a function or something else that makes sense for that particular parameter depending on what the method/function does. Pandas has a lot of overloaded parameters because it's a big library that covers a lot of use cases for tabular data.
Django/Jupyter/pandas is an ecosystem that's hard to beat. If you're not already using it, check out `django-extensions`. You can use `./manage.py shell_plus --notebook` to launch a Django-friendly Jupyter notebook. From there you can prototype with extreme ease and confidence. I have also built a trivial custom model Manager so I can do stuff like: User.objects.all().to_dataframe("first_name", "last_name", "email")…
What am I missing with data-frames?
I've written products that utilized them before (years ago), but it's been long enough that I don't know what I would even use them for in daily programming.
What I find most curious about Django/Python is that about 30% of the new installs are for legacy Python/Django (2.7/1.11): $ pypinfo --start-date 2019-01-01 --end-date 2019-03-31 -- percent --markdown django pyversion Served from cache: False Data processed: 160.22 GiB Data billed: 160.22 GiB Estimated cost: $0.79 | python_version | percent | download_count | | -------------- | ------: | -------------: | | 3.6 | 39.…
Not to bring back an old debate, but I simply want to point out the obvious: many data scientists disliked Python 3.x. I work with Python people who dislike Python 3.x, and we are still using mostly 2.7, because everyone feels comfortable with it. The upgrade seems to be a large imposition, with zero gain.
The lack of (enough) incentive for upgrading used to be a good excuse but with 3.8 we are getting a few performance updates that are hard to ignore. Also, many projects in data sciences are dropping support for legacy Python so sooner or later data processing pipelines will have to catch up.
Yes, upgrading is unpleasant, but it is becoming a matter of hygiene.
The projects/app relationship never 'clicked' with me. I also have a dislike for the awkward 'polls' example in the django tutorial. That said, I like Django. Of course, I liked Rails better, but maybe that's because it was my 'first' and I never used any of the big php frameworks for a long period of time. I quit wasting my time with Flask for projects a while ago. It's a really great project and suited for smaller…
I feel the same way. Does any one have a good overview on how the community actually separates functionality into “apps”? I have been looking at a rails like framework in python called Masonite. Does anyone in the python/Django community think this will gain traction?
* manage.py
* project/settings.py
* project/urls.py
* project/models/ (each model gets it's own file here)
* project/views/ (same for views)
...and so on. And in `INSTALLED_APPS` I just add 'project'.
Makes it so I don't waste a bunch of time trying to figure out which app to put a model in, etc.