Live data from Hacker News

What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

bitecode.dev

41–50 of 63 posts

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#41
post #25
post #8

What I love about Django is that you can create a Django project with just one file. You can turn a fresh Debian machine into a running Django web app by just doing: apt install -y python3-django apache2 libapache2-mod-wsgi-py3 And then creating the one file Django needs: /var/www/mysite/mysite/wsgi.py: import os import django from django.core.wsgi import get_wsgi_application os.environ.setdefault('DJANGO_SETTINGS_MO…

Blown away this is possible. When I was starting to learn to code and was overwhelmed when learning all the bits and pieces of rails, I wondered if everything necessary to run a very small app could be placed in a single file. I guess this is the answer, but in python/django instead of ruby/rails. It would be a fun exercise in ruby/rails too (not totally sure if it's possible, but suspect it may be, albeit probably r…

Not that I think this is pratical or even looks good, but its also doable with rails

  require 'bundler/inline'

  gemfile(true) do
    source 'https://rubygems.org'

    gem 'rails', '~> 7.1'
    gem "sqlite3", "~> 1.4"
  end

  require 'rails'
  require 'active_record/railtie'
  database = 'app_development.sqlite3'

  ENV['DATABASE_URL'] = "sqlite3:#{database}"
  ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: database)
  ActiveRecord::Schema.define do
    create_table :my_table, force: true do |t|
      t.integer :my_table_id
    end
  end

  class App 
For very small apps on ruby land sinatra and roda are the right choices. On python the choice would be flask instead of the single file django.

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#42
post #25

Earlier quoted context omitted.

Blown away this is possible. When I was starting to learn to code and was overwhelmed when learning all the bits and pieces of rails, I wondered if everything necessary to run a very small app could be placed in a single file. I guess this is the answer, but in python/django instead of ruby/rails. It would be a fun exercise in ruby/rails too (not totally sure if it's possible, but suspect it may be, albeit probably r…

Not that I think this is pratical or even looks good, but its also doable with rails require 'bundler/inline' gemfile(true) do source 'https://rubygems.org' gem 'rails', '~> 7.1' gem "sqlite3", "~> 1.4" end require 'rails' require 'active_record/railtie' database = 'app_development.sqlite3' ENV['DATABASE_URL'] = "sqlite3:#{database}" ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: database) Acti…

Is the db mandatory in Rails or could the db specific lines be removed from the code if no db is needed?

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#43
post #8

What I love about Django is that you can create a Django project with just one file. You can turn a fresh Debian machine into a running Django web app by just doing: apt install -y python3-django apache2 libapache2-mod-wsgi-py3 And then creating the one file Django needs: /var/www/mysite/mysite/wsgi.py: import os import django from django.core.wsgi import get_wsgi_application os.environ.setdefault('DJANGO_SETTINGS_MO…

Yes but how do you go about defining an ORM model without an app init class?

A lot could be said about it, but the first thing that comes to mind is that not every application uses a db.

And not every application that uses a db needs an ORM.

You probably can build an ORM into the single file. But I'm not saying every application should be developed as a single file forever. I just like that you can start with one and expand later.

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#44
post #42

Earlier quoted context omitted.

Not that I think this is pratical or even looks good, but its also doable with rails require 'bundler/inline' gemfile(true) do source 'https://rubygems.org' gem 'rails', '~> 7.1' gem "sqlite3", "~> 1.4" end require 'rails' require 'active_record/railtie' database = 'app_development.sqlite3' ENV['DATABASE_URL'] = "sqlite3:#{database}" ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: database) Acti…

Is the db mandatory in Rails or could the db specific lines be removed from the code if no db is needed?

Not mandatory, you could remove that

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#45
post #43

Earlier quoted context omitted.

Yes but how do you go about defining an ORM model without an app init class?

A lot could be said about it, but the first thing that comes to mind is that not every application uses a db. And not every application that uses a db needs an ORM. You probably can build an ORM into the single file. But I'm not saying every application should be developed as a single file forever. I just like that you can start with one and expand later.

Then you don't need django, flask and fast API already does all that withing a single file.

What makes django useful is the admin, auth, session and so on that are all built around the ORM.

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#46
post #42

Earlier quoted context omitted.

Is the db mandatory in Rails or could the db specific lines be removed from the code if no db is needed?

Not mandatory, you could remove that

Cool. What would be the steps from a fresh Debian to get it running and see it in action?

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#47
post #43

Earlier quoted context omitted.

A lot could be said about it, but the first thing that comes to mind is that not every application uses a db. And not every application that uses a db needs an ORM. You probably can build an ORM into the single file. But I'm not saying every application should be developed as a single file forever. I just like that you can start with one and expand later.

Then you don't need django, flask and fast API already does all that withing a single file. What makes django useful is the admin, auth, session and so on that are all built around the ORM.

You never know into what a project will develop. So it is nice to know you can expand it into anything, even when you start simple.

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#48

Earlier quoted context omitted.

One thing I have learned after nearly a decade in the industry is that you should just never, ever, ever use `celery`. It's overly complicated to program with; the monitoring tools are not great; and the one guarantee you can make is that at some point, you will have some kind of difficult to debug, mysterious failure involving it. If I needed asynchronous background processing in Python today, I'd definitely be look…

Does Django-tasks support different workers with different environments? Say I need a worker with GPU capabilities, can it do that?

I don't have any idea. Take a look here: https://github.com/RealOrangeOne/django-tasks

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#49
I have been doing Django for most of the last 10 years and I love it. I love Python. I love how well made are most of its core parts. And I love how some 3rd party packages (DRF aka django-rest-framework, django-filter, django-storages) fill the "missing" gaps.

That said, boy does Django must change it's current strategy...

RoR and Laravel have been getting all sort of goodies baked in the framework itself such as tasks queue, nice admin features, integration with frontend technologies (scss, js, even jsx/tsx), even entire packages to manage payment systems, mailing and so on... Good quality features that are ready to use and are integrated inside the framework, which easy to use APIs and fantastic admin integration.

Django devs, on the other hand, have been (imho) ignoring the users (devs) and have been denying any and all attempts at bringing something similar to Django. There are at least half a dozen packages for each "thing" that you want to do, and some are in a very good shape, but others are just hopelessly broken. What's even worse, because they're not part of Django, most of the time there are some edge cases that just can't be implemented without subclassing Django's core.

One of the most recent examples being Django's support for async operations. Except that Django itself doesn't provide a nice way to create / expose an API, which is why people use DRF. But DRF doesn't support async, which is why you need to add "adrf" (https://github.com/em1208/adrf) to DRF. But adrf doesn't support async generic viewsets, so you must add aiodrf (https://github.com/imgVOID/aiodrf) to adrf. But aiodrf doesn't support (...) you get the point. You end up in a situation in which you're pilling packages on top of packages on top of packages just so you can have an asynchronous API. Madness.

Supporting scss it another example of pilling packages on top of packages. It just never ends...

I can't express the desire I have for Django to start integrating packages into its core and get on par with RoR and Laravel.

/rant

Re: What's up Python? Django get background tasks, a new REPL, bye bye gunicorn

#50

Earlier quoted context omitted.

Here's how much is installed when you do `pip install django` currently: 122370 django python=103934,javascript=18407,xml=29 2734 sqlparse python=2734 1110 asgiref python=1110 This will probably change when `django-tasks` gets merged in. Here's what installing `flask` + `sqlalchemy` pulls in: 141314 sqlalchemy python=141314 11464 werkzeug python=11159,javascript=305 8934 greenlet cpp=4993,python=2729,ansic=1092,asm=1…

I suspect that people come to the conclusion that Django has performance issues by looking at synthetic benchmark rankings between frameworks. In that sense it may or may not be relatively slow, but it is probably fast-enough for almost all web services in-practice. And if you measure with all of the speediest HTTP interfaces and find out it isn't fast-enough, then frankly Python is probably not the right choice at a…

I've never heard of anybody complaining about Django per se having performance issues. When people say Django is "heavy weight," I tend to think of how it bundles a lot of stuff for you, which can make it easy to build an app; while, at the same time, if you end up deciding you want to step slightly off the garden path and do things juussssst a little differently than Django wants you to, you're probably gonna have a bad time.

OTOH, Flask is too small to impose much of a conceptual framework on you, and SQLAlchemy generally feels like a fairly thin layer of Python syntactic sugar over top of SQL. When I write queries in SQLAlchemy, it seems like they always tend to come out looking more like what I would write in plain SQL than queries in Django do. Granted, both ORMs can start doing things like joining tables behind your back, which can certainly cause performance problems, but that's a problem that's common to both, and not just Django. ¯\_(ツ)_/¯

Post reply on HN