Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 2.2

djangoproject.com

Post reply on HN
Print view View original

221–230 of 257 posts

Re: Django 2.2

#221

Post by bshipp »

lkrubner wrote: post #167
scardine wrote: post #73

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.

Given the amount of mojibake I've had to clean out of databases I'd have thought that data scientists would be the first to latch on to sane Unicode handling instead of the willy-nilly string handling inherent with py2.

Re: Django 2.2

#222

Post by RussianCow »

ibejoeb wrote: post #152
mkolodny wrote: post #121

I love Django. I've used it for the last 8 years. I'm happy to see the project is still thriving. At this point, for me Django is pretty much synonymous with Django REST framework ( https://www.django-rest-framework.org/ ). I can't imagine a better API than Django w/ REST framework. For static sites I use Django's templates. Otherwise, I just use Django w/ REST framework for my API, and to serve up index.html. My ind…

DRF is awesome. If you're considering moving to or implementing GraphQL, though, Django + Graphile is amazingly productive and performant. No affiliation, just good experiences. https://www.graphile.org/postgraphile/

If you're using Postgraphile for the API layer and a frontend framework for the view layer, what do you need Django for? Just migrations?

Re: Django 2.2

#223

Post by digitaltrees »

jarcoal wrote: post #180
digitaltrees wrote: post #72

Earlier quoted context omitted.

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?

I don't use multiple apps anymore and instead treat the project as the app, so my directory structure looks something like this ('project' can change to something specific to what you're working on): * 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…

That looks like rails. What made you settle on this given that Django promotes a different structure? I am curious as I like this approach as well, but would be nervous about making life harder by not following the framework and community path.

Re: Django 2.2

#224

Post by digitaltrees »

Alex3917 wrote: post #82
digitaltrees wrote: post #72

Earlier quoted context omitted.

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?

> Does any one have a good overview on how the community actually separates functionality into “apps”? For the most part there isn't any need to, with the exception of things explicitly meant to be shared. So if you are a large company and want a bunch of custom auth logic or something to be shared among many different teams running their own Django service, then you might want to build that as an app. Or else if you…

Thanks for the thoughtful response. Do you find yourself repeating code, or struggling to decide where code should live and where it should be imported?

Re: Django 2.2

#225

Post by Alex3917 »

digitaltrees wrote: post #224
Alex3917 wrote: post #82

Earlier quoted context omitted.

> Does any one have a good overview on how the community actually separates functionality into “apps”? For the most part there isn't any need to, with the exception of things explicitly meant to be shared. So if you are a large company and want a bunch of custom auth logic or something to be shared among many different teams running their own Django service, then you might want to build that as an app. Or else if you…

Thanks for the thoughtful response. Do you find yourself repeating code, or struggling to decide where code should live and where it should be imported?

I had this problem for the first couple years, but not anymore. What I did:

- I split the core app up into different views and services based on the functionality. For FWD:Everyone this is basically: account_management, admin_apis, content_discovery, organizations, upload_thread, read_thread, comments, and user.

I have a folder for all my views and a folder for all my services, and for each view there is one (or occasionally two) service files.

So e.g. in the views folder there is a file called account_management_views, and then in the services folder there is a file called account_management_service.

For utilities that get re-used across the entire app I have two additional things in the services folder, one is called util.py and the other is io_util.py.

Util is for things like sanitizing XSS that don't require any database access, and io_util is for things like get_user_from_username, get_user_from_email_address, etc.

Then you can import any models into io_util.py, but never into util.py. And you can import anything from util.py into io_util.py, but never the other way around. Then you can import anything from either util or io_util into any service method and shouldn't have any issues. (Although I always just import util or io_util, and then call the methods like util.sanitize_xss.)

Once I structured the services and utilities that way I never had issues again with circular imports or figuring out where to put stuff. Importing with Python is kind of difficult and janky in general, but so far this pattern seems to be working pretty well for both our startup and also for the consulting projects I've done.

Basically for logic that's mostly specific to a single view, put it in the services file for that view. Public functions in that folder can still be re-used in other services, but if they're fairly generic and they're re-used in more than one or two places then consider moving them into util or io_util so as to avoid circular import issues.

Re: Django 2.2

#226

Post by true_religion »

Godel_unicode wrote: post #102
sparkling wrote: post #28

Earlier quoted context omitted.

I have used both Ruby on Rails and Django in large production web applications over 2+ years. Speaking strictly about the web framework, RoR is the slightly better framework IMHO. This includes but is not limited to: - cleaner internal APIs, models, methods - a lot more stuff that "just works" out of the box where you would need a third-party package in Django (e.g. RoR gives you different settings for development/st…

> better static file handling Don't you just let nginx/CDN handle these?

Asset Pipelining is a dingo plug-in, but a built in for Rails.

Re: Django 2.2

#227

Post by jarcoal »

digitaltrees wrote: post #223
jarcoal wrote: post #180

Earlier quoted context omitted.

I don't use multiple apps anymore and instead treat the project as the app, so my directory structure looks something like this ('project' can change to something specific to what you're working on): * 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…

That looks like rails. What made you settle on this given that Django promotes a different structure? I am curious as I like this approach as well, but would be nervous about making life harder by not following the framework and community path.

Been building Django apps for almost 10 years and after seeing the amount of wasted time going into organizing things into apps, I settled on this technique.

It doesn’t really swim against the current as long as you import models into the __init__.py file in their package.

Re: Django 2.2

#228

Post by airstrike »

ecmascript wrote: post #87
chickenfries wrote: post #61

Earlier quoted context omitted.

Free software is a political movement. Calling it “free” was a political choice to convince people that proprietary software is “unfree”. I really don’t know where to begin explaining this...

Well yes, but they are not policing speech as far as I know. I have nothing against people/projects being political, it's when a specific political view that I do not agree with gets enforced upon me that the issue arises.

Companies and institutions have every right to define what is acceptable speech in their own universes

And freedom of speech isn't an absolute right – not even in the U.S., but even less so in pretty much any other advanced Western democracy.

Re: Django 2.2

#229

Post by howiroll »

mtberatwork wrote: post #45
Alex3917 wrote: post #19

Earlier quoted context omitted.

With Python you get: - The best-governed language in all of software, and the best-governed web framework - A huge ecosystem of libraries for everything from data science to email processing, that are (mostly) easy to read and modify and free from systemic security issues. And pretty much every major company with an API has an official Python library for that API. - The standard language taught at most of the top CS…

Django's documentation is also simply top notch.

I disagree. There are too much undocumented potholes.

Re: Django 2.2

#230

Post by AdamM12 »

andrewstuart wrote: post #189
bluedino wrote: post #42

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 quit wasting my time with Flask for projects a while ago. It's a really great project and suited for smaller things, but you just end up re-implenting django This is spot on .... Flask is great, but it seems that to get anything substantial done with Flask you must first reimplement big chunks of Djangoesque functionality in it - why not just jump straight to Django?

Yeah that or just plug in 5-6 extensions and you end up with the same. Found myself doing flask-sqlalchemy, flask-migrate, etc. after a while.
Post reply on HN