Hacker Newsnew | past | comments | ask | show | jobs | submit | BrenBarn's commentslogin

I think if it we want to stop killing the internet, the lack of regulation of AI/bot companies is the biggest problem right now.

The other thing is that I find a fair number of "news" stories these days are basically one or two small details about the latest update on some ongoing situation, followed by a long summary of what happened before. So most of the news is already old.

I've come to see this kind of response as sort of akin to "but what if I like driving my old clunker car that gets 15mpg and spews smog"? It's not wrong exactly, but it just amounts to saying "I became accustomed to receiving certain benefits before we as a society became fully aware of the accompanying costs, and I just want to maintain the lifestyle I've become accustomed to". I think in the end the costs of the convenience provided by these kinds of things simply aren't worth it and are a net negative for our world.

Whether or not the decline of literacy is a pearl-clutching myth, I don't think anything is gained by laying on a bunch of academic mumbo-jumbo about "literacies" and "problematizing" things and contextualization and how everything is more complex and nuanced than we realize. That kind of theorizing takes us further from knowing about reality rather than closer.

In particular, trying to repurpose words like "literacy" from their typical usage into some kind of broad and encompassing notion is a classic and classically frustrating maneuver of a certain kind of academic. It leads us to a world where we have a bunch of words that are all supposed to mean "a complex interplay between the individual, society, technology, and whatever else I feel like tossing in", and then we can argue about the differences between them. I'd rather skip that.

Saying that "literacy" includes everything people need to do to navigate in society is like saying that "music" includes making armpit noises. Yes, maybe you can stretch it to include that, but that's not what people use it to mean and it's not what people are talking about when they say literacy is declining. No one is going go "Oh gosh, you're right, people are now learning about 'navigating a social media platform' and 'producing a video essay' so I guess there's no literacy crisis at all!" People know that's happening, they just don't consider it literacy, and trying to redefine literacy to include it is just sophistry.


> trying to redefine literacy to include it is just sophistry.

Or an angle toward one's doctoral dissertation in some "social science" or other.


Maybe not "all" in the sense of every word, but I think a good number were at least taking a stab at each assignment, and even more were taking a stab at most of the assignments. It's hard to know for sure without some kind of hard data but my impression is there's been a shift from a situation where by default people "basically" did do the reading to now where by default they basically do not.

I mean one thing is that exercise is good for your general health, so maybe there's a reluctance to tie it to specific conditions like depression.

> It's fine + obligation to fix, and daily fine until fixed, and higher fine if you do it again.

The important proviso is that the penalties need to (on some non-geological timescale) get high enough that the offender is no longer capable of operating. That could mean the fines reach $500 billion, or it could mean the company is barred from operating in the EU, or it could mean people get arrested and assets are seized. But unless the penalties become crippling, it won't matter. It needs to reach a point where the downsides of noncompliance are actually greater than the benefits.


NIS2 allows for the arrest of managers in case of cybersecurity incidents resulting from negligence. I think it's a step in the right direction, but we'll have to see how it plays out.

In the EU they like the "daily fine until fixed". It's how Microsoft bowed down.

But unlike the story some on HN and in the US like to think, US tech companies don't ever get there except rare exception, they know the game.


The Django filter syntax with the double underscores is like fingernails on a chalkboard to me. I find it insane that they didn't just use operator overloading to create a real query expression language.

I think you can do that with querysets, Q, and F. The kwargs are a limited convenience.

Or now that python has ~types, this is really an area where things could be improved. Filtering would just be lambda predicate with fields auto complete as seen in .NET, scala, etc

There may be many reason other than rejecting that suggestion leading to what it is know. Your statement somehow suggests that it was deliberately decided against what you propose. I don't think we know that.

I can't quite picture how operator overloading would look like, could you give an example?


> I can't quite picture how operator overloading would look like, could you give an example?

Instead of this:

self.filter(end__gt=self._midnight(today))

You could write a "Field" class that implements __getattr__ and __gt__ so you could do

self.filter(Field.end > self._midnight(today))

The "Field.end > self._midnight(today)" would evaluate to an object that would just store "my field name is end and my value needs to be larger than xyz".

filter() can then look into its argument list and construct the filter criteria from the passed Field objects instead of the key value pairs as it does now.


SQLalchemy does that. One advantage of the Django syntax is that it can be (pretty much) directly dropped into a query string on any admin page or DRF query and filter the results. E.g. the admin page for all the events after noon today:

  admin/event/?end__gt=2026-07-26T12:00:00
Being able to do ad-hoc queries using the same paradigm your app queries are written in, and then pass urls around with those queries included (e.g., quick one-off reports or answers to client questions) is so helpful.

This convenience sounds a little dangerous. Would this allow the user to specify e.g. joins or SQL procedure calls using the query parameter?

if self._midnight(today) returns a datetime object, than:

   self.filter(end__gt=self._midnight(today))
will evaluate to:

   self.filter(end__gt=<some_datetime_object>)

While

    self.filter(Field.end > self._midnight(today))
will evaluate to:

   self.filter(<True/False>)

No it won't, because there's no requirement that the result of `>` be True or False. It can return an object that then can participate in further expressions that "keep track" of what operations are done to the fields.

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)

    class Field(metaclass=FieldMeta):
        pass

    print(Field.end > datetime(2024, 1, 1))
This gives:

    {'field': 'end', 'operator': '>', 'value': datetime.datetime(2024, 1, 1, 0, 0)}
You can make python return arbitrary values for comparisons by overriding __gt__ (and lt, eq) on the first operand (which we control here since it is a Field class), it doesn't have to be a bool.

Edit:

You can even make a little adapter to use this with the current filter system if you really want to:

    from datetime import datetime

    class Filter():
        def __init__(self, name):
            self.name = name
        def __gt__(self, value):
            return {
                "field": self.name,
                "operator": "gt",
                "value": value
            }
        
        def __lt__(self, value):
            return {
                "field": self.name,
                "operator": "lt",
                "value": value
            }
        
        def __eq__(self, value):
            return {
                "field": self.name,
                "operator": "eq",
                "value": value
            }

    class FieldMeta(type):
        def __getattr__(cls, name):
            return Filter(name)

    class Field(metaclass=FieldMeta):
        pass

    def _(*args):
        kwargs = {}
        for arg in args:
            k = arg["field"] + "__" + arg["operator"]
            kwargs[k] = arg["value"]
        return kwargs

    def filter(**kwargs):
        for k, v in kwargs.items():
            print(f"{k} = {v}")

    filter(**_(Field.end > datetime(2024, 1, 1)))
This prints

end__gt = 2024-01-01 00:00:00


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...

If you change an operation that is meant to return a Boolean to return anything else, you are insta fired.

I would have agreed with this, and then they did the `pathlib.Path` bit of cuteness with the `/` operator: https://github.com/python/cpython/blob/5afbb60e0283caaf34990...

And despite my misgivings, it’s really ergonomic.


If you divide a Path by another Path, you get a Path. If you compare two Paths, you get a Boolean. It is not really the same.

That's a well established pattern in Python, for instance with Numpy. That's the point. Operations in Python aren't "mean to return" anything in particular. Each class can define the operations as it wants. That's a powerful feature that allows creation of specialized expression languages, as used by other ORMs besides Django.

Hi, don't mind me, but

You don't need to return a boolean. You need to return an object that implements __bool__.

Get it ?

And even then, when you're dealing with objects that are special to expressions, you don't actually even need __bool__ that much


You mean like the numpy authors that let the comparison operators return arrays?

Also, apparently SQLAlchemy does exactly what I proposed so apparently they are erring in their ways too.

I honestly don’t find it that bad.


How would you model string comparisons with LIKE?

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.

You might want to look at Peewee's query filtering syntax.

https://docs.peewee-orm.com/en/latest/peewee/querying.html#f...


I have, yeah. That's kind of my point: other ORMs do this better than Django.

> There are serious questions about copyright, labor, energy use, slop, and maintainers drowning in generated contributions. But these tools are also becoming part of how software is made. The Open Source world needs to figure out how to engage with that future, not just divide into camps.

Everyone who says stuff like this is just burying their head in the sand. That is like saying that there are serious questions about the ethics of buying sweatshop-made clothes, or driving a gas-powered car, or robbing grocery stores --- but those are becoming part of life, and so we need to "figure out how to engage with them".

That doesn't mean you have to upend your life to fight the good fight. You can say "I want a world without X, but right now I need X to live, so I do X, while maintaining an awareness of it and looking for opportunities to do less X". You can say "I want a world with some kinds of X but not others, so I do the X that I'm okay with". You can even say "I think X is ethically fine so I'll do it". But it just doesn't make sense to say "there are ethical issues with X, but those only affect how we engage with it, and have no bearing on whether we think people should need to engage with it at all".

There can't be ethical consideration of "how" without at least considering the ethics of "whether".


Deciding that you "won't make moral judgments" is also a moral judgment. It's just a less obvious one. All platforms have made moral judgments in the past, and will continue to do so in the future. Some of them just don't realize it.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: