[dfee]

Your point is interesting, and it’s how I’ve designed a lot of APIs when I’m not sure how I’ll end up needing the class or function the most: slightly less ergonomic in the know use case, but across the board it has a higher “median” ergonomicity. A third alternative of course would be to add a method to the constructor, specifying this behavior (e.g. write_depth=1).

However, it appears that the “locals, globals, builtins” lookup was the design constraint this was intended for, and the core of Python seems to prefer new classes over compact functionality. For example look at OrderedDict not just being an “ordered=“ keyword only parameter (ordered) on dict.

[joshuamorton]

That design would have made ordered dict incompatible with dict (an ordered dict couldn't be constructed with an ordered key, same for an unordered dict), and at the time, keyword args were unordered, so an ordered dict had to be constructed with an iterable of tuples instead of key value pairs.

[dfee]

I disagree. There’s a strange precedent for builtins overloading like ‘type’. The same could be done for ‘dict’. Do you want me to share a satisficing call signature?

[joshuamorton]

Type doesn't take in kwargs?

But yes, I'm interested in the call signature you propose such that it's possible to tell whether

    dict(ordered=True)

Means `OrderedDict([])` or `{'ordered': True}`.