Compare it to C, which it has displaced as an introductory language. Python and C are superficially interchangeable to a beginner, but to learn C you have to invest time into pointers and memory management. Python sacrifices the efficiency of direct memory management to avoid the complication of pointers. Arguably, this is a significant benefit because it also cuts down on ways to introduce bugs.

Compare it to a Lisp - Python has a pretty inferior set of basic capabilities (can't even use a dict as a dict key, drives me mad), but that just means there is only one easy way to do things that everyone uses. Less room to think up clever ways of doing things, less complexity reading other's code.

Being the 'best' language for a task has a huge cost - incidental complexity created by including specialist constructs. Python's success suggests maybe programmers prefer this complexity to be encapsulated in a library rather than the language core.

Curious, is this actually something you want to do often? While there is no hashable+immutable frozendict ala frozenset, you could throw one together or even define a hash function on a subclass and "swim at your own risk" not to mutate it later.

I've encountered this enough with lists and the obvious solution is to cast them to tuples. Can't say I've found the same with dicts tho.

As for the comparison with lisp - in most lisps this is a non issue because nearly all structures are immutable

Many major programming languages undersell how natural key-value data structures are; usually by providing unwieldy mapping data types. Clojure has spoiled me.

> you could throw one together

Yeah, I do. Most Python programmers wouldn't see a need for that, but that can be attributed to Python not having the capability by default and so they've just internalised not to use dict for anything that needs to be a key. World's mildest form of learned helplessness, I suppose.

You're being extremely uncharitable here.

To a Python programmer "using a dict as a key" is a nonsensical idea for the same reason "using a list as a key" is — both dicts and lists are mutable. Python programmers don't think of dicts or lists as synonymous with their content.

I'm assuming you don't want to literally use a dict as a key, you want to use the keys and values contained in a dict as a key. Nothing stops you. You just have to say it:

    point = dict(x=4, y=5, z=1)
    point_reviews = dict()
    point_reviews[tuple(point.items())] = "A+++ great coord would point to again"

    point = dict(x=0, y=9001)
    point_reviews = dict()
    point_reviews[point] = "Love how it's over 9000 here!"
    point["y"] = 8999
    result = point_reviews[dict(x=0, y=8999)]  # Is this a KeyError or not?

In the simplest case where you have a predefined list of keys, I'd suggest using a namedtuple instead of a dict. If you need to treat a dict's content as hashable but can't enumerate the keys, `tuple(d.items())` is probably the best choice in recent Python versions. Be aware though that in older Pythons you can't rely on stable sort order of dictionary items, so you have to use something like `frozenset(d.items())`.

    >>> tuple(dict(a=1, b=2).items())
    (('a', 1), ('b', 2))
    >>> tuple(dict(b=2, a=1).items())
    (('b', 2), ('a', 1))

    >>> frozenset(dict(a=1, b=2).items())
    frozenset({('b', 2), ('a', 1)})
    >>> frozenset(dict(b=2, a=1).items())
    frozenset({('b', 2), ('a', 1)})

    dict(a=1,b=2) == dict(b=2,a=1)

    >>> a = {}
    >>> x = id(a)
    >>> del a
    >>> a = {}
    >>> y = id(a)
    >>> x == y
    True

Give them a string, they return a table or function. Give them the table or function, they return a string.

It’s a useful technique that you can only apply if your hashmap can map anything to anything.

Any hashmap will have problems with storing mutable objects, where the hash value itself can change after the object has been stored, causing some very unwanted paradoxes.

And that is the problem with Python dicts as keys.

I just assumed it was the former, based on the fact that dicts are disallowed as keys.

The reason for that choice is because the object is mutable.

You can still create a hashable key from a dict with FrozenSet(mydict.items()).

tuple(d.items())

    >>> tuple({1:2,3:4}.items()) == tuple({3:4,1:2}.items())
    False
    >>> frozenset({1:2,3:4}.items()) == frozenset({3:4,1:2}.items())
    True

dict = { "foo" : "bar" }

set = { dict : true }

set.has_key?(dict) # true

I'm sure there are other use cases where dict keys can be convenient.

someset = {"one", "two", "three"}

"one" in someset # true

frozen = frozenset(someset)

somedict = {frozen: "example"}

frozen in somedict # true somedict[frozen] # "example"

I would think a NamedTuple would do the trick? (https://docs.python.org/3/library/collections.html#collectio...)

Golang, by contrast, is really quite schizophrenic sometimes about whether it wants to be a high or low level language.

Outside of lisps, I find Python to be one of the simplest syntaxes, so the only effort is the logic to solve the problem.

but often better than master of one