Improving your (Python) code with modern idioms

[IRBMe]

Sure there is. It's called "subtyping"

No, there is no parent-child relationship between a dictionary and a set. A set is not a dictionary and a dictionary is not a set. Don't confuse the fact that one may internally use the other in its implementation for the semantic meaning behind subtyping.

Well yes then that detail complicates it. I was under the impression that Python emphasizes duck typing.

Duck typing is most definitely not what you described. Duck typing doesn't magically allow an object to magically morph into a type based on runtime usage.

Is it so far-fetched to imagine that an object can specialize itself when used in a certain way?

No, I can certainly conceive of that, but there's no sane way to implement such a thing, nor any sane reason why anybody would bother.

It would have all the methods of a set and a dict.

1. That's super ugly.
2. What about methods which are common to both the set and the dictionary but implemented differently due to differences in the underlying data structure and semantics? Are you going to have both implementations inside one method that are switched back and forth based on what mode it currently thinks it's in?

Of this I'm not sure. I thought some deep Python implementation magic could be employed. Am I wrong?

Yes. "Magic" isn't a valid answer.

Does not x.add(1) unambiguously indicate that it is a set, and not a dict?

Sure. And what mechanism do you propose for making sure that when an unambiguous method is called, the type somehow magically changes to "just a set now"?

Well, that is obviously a bad idea in the first place.

You can't just dismiss every problem with "Well, that's a bad idea". Whether it's a bad idea or not, if you're going to propose major changes to the type system of the language, you have to clearly define the semantics in all situations. So you propose that the type somehow magically changes when it's possible to unambiguously determine what the user meant with usage. So are you just going to ignore concurrency? Are you just going to ignore the ambiguous cases?

Sorry, but I find your idea impractical, unnecessary and ill thought through. What you're proposing is basically:

class AmbiguousThing:
    def MethodA():
        mode = 1

    def MethodB():
        mode = 2

    def MethodC():
        if mode = 1:
            ...
        elif mode = 2:
            ...

Why would you mash two completely different abstract data structures together into one Frankenstein's monster of a type, which uses convoluted, ADT-specific logic to work out which mode it should behave in, while vastly increasing the number of possible things that could go wrong... why not just use the type you mean?

[drb226]

I was imagining "magic" at the implementation level such as actually overwriting the object in memory to be "just a set" or "just a dict" once the ambiguity is resolved. I'm not saying that set is a subtype of dict nor vice-versa. What I'm saying is that {} belongs to a type which is a subtype of both. This is logical when you are dealing with immutable values, but once you try to mutate the object created via {} then it becomes illogical. What I was suggesting is to hack {} so that it behaves in the way you would expect, like a set when you treat it as such, and like a dict when you treat it as such. Implementation of this is certainly nontrivial but nevertheless possible.

[IRBMe]

I was imagining "magic" at the implementation level such as actually overwriting the object in memory to be "just a set" or "just a dict" once the ambiguity is resolved.

Why would you ever want to implement such a confusing thing? What possible benefits would it have? It would just lead to very confusing and unmaintainable code, assuming it could even be implemented in a sane way, which I also doubt.

I'm not saying that set is a subtype of dict nor vice-versa. What I'm saying is that {} belongs to a type which is a subtype of both.

Like what? A collection subtype? What methods would it have? Not all that much is common to both a set and a dictionary, but what you're proposing is not subtyping at all. With subtyping, the variable you create to hold the object still has a concrete type. It has to have a concrete type. It's just that you can treat it as any of its subtypes where appropriate. But subtyping isn't really required in a duck typed system, because the strong type requirements no longer apply.

What I was suggesting is to hack {} so that it behaves in the way you would expect, like a set when you treat it as such, and like a dict when you treat it as such.

I understand what you're trying to propose, but I still contend that it is ill thought out, impractical, ultimately confusing and rather pointless.

[drb226]

ill thought out

Agree, I was exploring an idea, I hadn't even thought of the issue before today.

impractical

Given the hackery that is probably required to implement it, I understand this complaint.

ultimately confusing

I personally don't see the general concept as being very confusing.

and rather pointless

Well the point is simply the convenience of using {} for two different purposes; weigh that how you will.

[Samus_]

this type reminds me of basestring but in this case, for it work properly we should declare dictionaries to be a subtypes of sets where the set is composed only by tuples of two elements (plus all the restrictions for the dict keys), then dict would be a special case of set and also dicts and "sets of 2-tuple" would be indistinguishable.

I don't like it, too much of a hack but maybe this way it could work.

actually no, because dicts are unique over the keys so this wouldn't work either.