Hacker News Reader

Comment by ezo | Hacker News Reader

I’m wonder, who’s thinking that dict() is more readable???

For string keys it can be as it is `dict(a=1, b=2, c=3)` vs `{"a": 1, "b": 2, "c": 3}`. There is a lot of `"` noise on the latter.

50% less noise with ‘ though dict is still slightly easier to read; you can also convey that the keys are supposed to be valid identifiers.

I wish I could do {a=3, b=2}

You can in Javascript - but with the caveat that the keys can only be strings.

Without that, if Python allowed it, would it do given:

  a = "xxx"
  test_dict = {a=3, b=2}

would it take test_dict to mean {"xxx":3, "b":2} or {"a":3, "b":2} ?

JS does the latter always, so the variable a is not related to the literal key a which is understood as an unquoted string "a":

  > a = "xxx"
  'xxx'
  > test_dict = {a:3, b:2}
  { a: 3, b: 2 }
  > test_dict["xxx"]
  undefined
  > test_dict["a"]
  3

The assignment operator `=` can never appear in a valid Python expression, so `{a=3, b=2}` should be distinguishable from `{a: 3, b: 2}`. (So does JS, where `{[a]: 3, [b]: 2}` would evaluate a and b.)

At this point, just use a dataclass.

Of course, for anything except string keys, that isn't even an option.

No great reason it couldn't be though:

dict(1=5, 6=7, 7="aaa")

dict(hashableInstance="foo", anotherHashableInstance=23, (1,5)=8)

except Python syntax choices of course.

Is 1 a integer or a string?

It's an integer (in the, not supported, format I show as something Python could have supported).

And if they wanted a string, they'd do it like:

dict("1"=5, 6=7, 7="aaa")

`{x, y}` is the set containing the two elements `x` and `y`, `{x}` is the set containing only the element `x`, so "surely `{}` is the empty set" !

If Python had had built-in set notation from the start, {} might indeed have been a notation for an empty set instead of an empty dict.

However, Python didn't even have sets at all until version 2.3, and they were in a stdlib module instead of being a built-in type until version 2.6. By that time dict notation was well entrenched.

One place where I prefer dict() is where dicts are used as "nested kwargs", e.g. in Django's ORM for passing default values.

    User.objects.get_or_create(
      username="bob",
      defaults=dict(
        email="bob@example.com",
      )

this makes it easy to move fields between `defaults` and `kwargs`. Granted, you could achieve the same isomorphism with ** operator, but less readably IMO.

I think dict(name=name, age=age) can be definitely be more readable and ergonomical to write than {"name": name, "age": age}.

I still miss coffeescript's ability to do dict(@name, @age) though I understand that it creates an unwelcome coupling between the parameter names and their names in the calling scope.

For my part, those names are often the same anyway, though, since the calling scope names are often arbitrary and might as well match the parameter names.

    {name, age}

does the same in modern JS, assigning the variable to the key with the same name.

dict() can be useful for enforcing (or indicating to the reader) that keys are strings and valid Python identifiers. {} allows arbitrary keys, as long as the data type is hashable.

I think it's more readable. It matches with the type name, it is consistent when you define different structures (list, set, dict vs [], set, {}), you can pass it as a function, etc. [] and {} is unnecessary syntax sugar, not to mention how the same parentheses are overloaded when sets are defined.

You could argue that since `{}` is also technically an empty set, `dict()` is more explicit.

Except `{}` is never an empty set.

> x = set()

> x

set()

Well now I know! However I still think the shared usage of curly braces for dicts and sets could be somewhat confusing.

> x = {1, 2, 3}

> x

{1, 2, 3}

(But maybe no one should listen to me because I don't know how to do code blocks on HN.)

Indent by four spaces. :-)

The empty set is `{*()}`.

never seen

    {*()}

but I guess it is equivalent to

    set()

I've noticed this in python in another place

    f"{var}"

is the same as

    str(var)

there was some other place I can't recall also noticing that (at least my perception understands that) Python is trying to kill my code golf tendencies.

That said, it's probably just my own superstition and of course it doesn't remove my premature optimization tendencies...

this is beautiful

I do. dict() costs me less eye strain to recognise out of the corner of my eye.

Why the triple question marks? You could have just asked the question straight.

less clutter for string-only keys.

Reply on news.ycombinator.com