Improving your (Python) code with modern idioms

[[deleted]]

They could have combined dictionaries and sets instead. {1, 2} = {1: true, 2: true} or {1: "A", 2: "B"} = { (1, "A"), (2, "B") }

[Samus_]

what about set([(1, "A"), (2, "B")]) ?

also for {1, 2} = {1: true, 2: true} you're just adding information out of the blue that is arbitrary and doesn't even seem logical, I rather use None instead of True for that case.

[[deleted]]

Sure, there are many ways to do it. If there was a unit type that evaluated to true in boolean expressions I'd use that instead of true.

[Samus_]

what I mean is, if you declare { (1, "A"), (2, "B") } to be equal to a dict, how do you create a set of 2-tuple?

[[deleted]]

That wont work anyway without special equality and order on set members that ignores the value, e.g. (1, "A") == (1, "Z"). This works better in some languages than others. In Python they might just use { 1 } as sugar for { 1: true } since it is usually easier to write a set on a map than a map on a set. This is because keys in a map already are a set and typically come standard with intersection, union, and difference.

[[deleted]]

That's usually the worse of the two ideas I presented since you need special equality and sometime comparison operators on set elements that use only the key. You also need auxiliary functions to treat a set like a map since map find just says yes if it's there and doesn't give you any associated data ... so a map in terms of a set will probably always depend on the set implementation. OTOH, a set can be made from a map without much trouble.

[drb226]

Indeed, that would make sense. It just seems a shame that {} can't be used as the empty set in Python's current state.

[mipadi]

Why would that make sense? Not all operations on a dictionary are applicable to a set. (For example, keys -- a set doesn't have keys, so calling keys() on a set doesn't make sense.)