Live data from Hacker News

Some more things about Django I've been enjoying

jvns.ca

81–90 of 128 posts

Re: Some more things about Django I've been enjoying

#81
post #24

Earlier quoted context omitted.

if self._midnight(today) returns a datetime object, than: self.filter(end__gt=self._midnight(today)) will evaluate to: self.filter(end__gt= ) While self.filter(Field.end > self._midnight(today)) will evaluate to: self.filter( )

Not if you do the magic with getattr and comparison overrides. You actually need to do it on the metaclass because the Field as I wrote it isn't an instance but this works: from datetime import datetime class Filter(): def __init__(self, name): self.name = name def __gt__(self, value): return { "field": self.name, "operator": ">", "value": value } class FieldMeta(type): def __getattr__(cls, name): return Filter(name)…

Do this:

  def __gt__(self, value):
      return Q(**{ f"{self.name}__gt": value })
and your original code should work as-is without the need for _()

  self.filter(Field.end > self._midnight(today))
https://docs.djangoproject.com/en/6.0/topics/db/queries/#com...

Re: Some more things about Django I've been enjoying

#82
post #79

For Django's default template language, does it still have these limitations? 1. Brackets aren't allowed to help with boolean expressions like {% if a and (b or c) %} 2. You can't do basic arithmetic like {{ x * 2 }}, but you're allowed to do {{ x | add:"2" }}. There's hacks to multiply using {% widthratio a 1 b %} or division with {% widthratio a b 1 %} though ( https://stackoverflow.com/questions/18350630/multiplic…

> It's like hiding the kitchen knives because they might be misused. I used to agree with this more strongly but over time decided the Django model was actually more effective as your cue to ask whether you should have been writing a Python function instead and calling it (which has been super easy since something like 1.4 or so IIRC). Unless you have a small, very diligent development team it always seemed to end up…

> over time decided the Django model was actually more effective as your cue to ask whether you should have been writing a Python function instead and calling it

I get the motivation, but is disallowing brackets and proper variables really the right way to do this? These make code clearer to read and reduce duplication more than they introduce complexity so this is going too far in my opinion and feels arbitrary.

Re: Some more things about Django I've been enjoying

#83
post #73

Earlier quoted context omitted.

For those you would have a method on the field object (e.g., `Table.field.like("whatever")`).

Yeah, but that's different from the operator. It's a different way of thinking about it. Maybe that's the reason they used dou le underscores for everything, to keep it consistent.

Not really. Both method calls and operators are consistent with how Python normally works. Outside of Django you never do `obj__op(value)` or `obj__meth(value)` to do the equivalent of `obj op value` or `obj.meth(value)`. It is Django that is inconsistent with how operations are done in Python.

Re: Some more things about Django I've been enjoying

#85

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

async python is always slower than just naively using threads. I don't think there is any application in production anywhere that would not prove me right on this. the complete lack of any kind of scheduling is a disaster. unless you know exactly what I mean by a scheduler please don't reply to this.

Re: Some more things about Django I've been enjoying

#86

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

Everytime I have to deal with websockets in Django, I want to rip my eyeballs out.

Most of the time what I really want is just push support, and don't need bidirectional communication, i.e. SSE. But it's the same thing: both are a pain to work with in Django. I find django-channels so cumbersome.

So, for my latest projects, I've ended up offloading this push functionality to a service like Centrifugo. Django talks to Centrifugo, and clients connect to it as well. It makes Django still be django, without worrying about django-channels, ASGI and all of that complicated setup. I've been very, very, very happy with this decision, even if I do have some additional complexity to articulate the two. It is nowhere near as confusing and convoluted as django-channels and uvicorn/daphne, though.

As for async python in general, fully agree. Every couple of years I decide to give it a go with some new tool or framework, thinking surely now it'll finally just click and I'll get with the times. Every time I feel disappointed with footguns and absolutely terrible ergonomics. No, thanks.

Re: Some more things about Django I've been enjoying

#87
automatic migrations terrifies me. i use elixir/ecto. just write a migration!

besides, some times you might want more than one schema for a db table (e.g. one with minimal information, for menus, dropdowns etc, and one with full information for your full CRUD operations)

Re: Some more things about Django I've been enjoying

#88

There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress. It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very p…

I agree that there's plenty of footguns with async python, but I think the hype is a bit overblown. A few sensible defaults in the standard library would go a long way, e.g. requiring a maxsize argument to Queue (or None if you really need it to be unbounded). The "accidental blocking" thing seems like less of design issue - it has much more to do with python's super long history as a sync-first language. Taking a step back, though, async is popular because it is genuinely extremely useful! If you need to do a bunch of work and that work is mostly IO-bound, then it makes sense to live in an async world.

Re: Some more things about Django I've been enjoying

#89
post #57

Not to be a downer since a lot of JEvans’ content is great. People should really give .NET a try. I don’t know if we are just old greybeard curmudgeons who look at this and go “is this a new thing? haven’t we been doing this for decades?”, but .NET out of the box with a few packages for databases, logging, etc is so pleasant you don’t even think about it. Maybe it’s just not a vocal community idk.

agreed 100%, the most under-appreciated programming ecosystem of them all. It's also the only one that has support for making truly native apps for all four major platforms: Windows, Linux, MacOS and iOS. If you're willing to put in the work and make separate, native UIs for each, C# is the only way to go. It's a rich enough language that it binds reasonably well to both Java (on Android) and Objective C / Swift (on…

> under-appreciated programming ecosystem

idk, for a long time nswag was the openapi framework and it was atrocious and had many core issues that were unresolved for almost a decade. it came to where i implemented an api with something basic (i think it was multipart) and one consumer of my api asked me to change the api because nswag couldn't handle it. i told them to pr a fix to nswag (they didn't).

Re: Some more things about Django I've been enjoying

#90

I mostly use Go + SQLite for all the things I used to use Rails, JavaScript, or Python for. I find python django wastes too much resources, just look at memory usage. One of my web app backend (go) is serving approx 100 req/s right now and i look at pprof i see it's not bottlenecked by CPU but mostly IO and i love this. Writing concurrent code in Go is easy, the code i wrote 10yrs ago still compiles with no issue! Th…

I dont understand the comparison of Go even with Sqlite and Rails or Django?

one is a programming language with a db server and the others are full stack web frameworks.

How fast can you create (without LLMs) an authentication system plus a form and saving the answers in DB (only for authenticated users) with sane default good secure protections in Go and Sqlite?

And assuming you are amazing at Go (and probably you are) then ask the same question above for any average Go developer vs any average Django or Rails developer.

Post reply on HN