Add a partial, covariant Mapping type

[harahu]

Addresses #5

[harahu]

@srittau Decided to make an attempt at implementing the protocol we discussed a while ago.

Is there a checklist for what needs covering in a PR to typing_extensions?
I'm thinking in terms of docs, testing and the like.

[srittau]

Side note: Depending on where #45 goes, this might be better suited for the new submodule.

[harahu]

Side note: Depending on where #45 goes, this might be better suited for the new submodule.

I agree. I was considering basing this PR off of your branch, but was unsure what the likely timeline for merge (and change potential) is like, so decided to just get started here.

[JelleZijlstra]

The main typing-extensions namespace should not contain names that don't have a prospect of going into typing. Potentially this could go into typing_extensions.util if and when we add that.

Aside, I don't like the name much.

[gvanrossum]

FWIW 'util' or 'utils' is a terrible name for a submodule. (And as I wrote in #5, I am not in favor of this PR in general, but I'll defer to Jelle+Sebastian.)

[harahu]

The main typing-extensions namespace should not contain names that don't have a prospect of going into typing. Potentially this could go into typing_extensions.util if and when we add that.

See comments above. This is the intention. Was just eager to get started. Hope you don't mind.

Aside, I don't like the name much.

I agree. The name is the part I struggle with the most. I have several other ideas, all of which I have trouble with:

• PartialMapping
• PartialMappingCo
• MappingLike
• MappingLikeCo

Suggestions welcome, in other words.

[harahu]

FWIW 'util' or 'utils' is a terrible name for a submodule. (And as I wrote in #5, I am not in favor of this PR in general, but I'll defer to Jelle+Sebastian.)

It would be constructive to provide an alternative to the claimed terrible name.

[gvanrossum]

FWIW 'util' or 'utils' is a terrible name for a submodule. (And as I wrote in #5, I am not in favor of this PR in general, but I'll defer to Jelle+Sebastian.)

It would be constructive to provide an alternative to the claimed terrible name.

Sorry, you're right. In my experience in any large code base there are dozens of leaf modules named util[s], and the name just doesn't convey any meaning. Worse, if you are tempted to write from foobar import utils now you have a utils global that could have been imported from many different places.

Even if we called it typing_utils that would be better. Depending on the intended use of this package we could name it more specifically but I haven't followed what it's for -- @JelleZijlstra or @srittau could probably comment. (Not clear that it belongs in this PR's discussion, except you alluded that putting it in such a submodule was your intention.)

[AlexWaygood]

Even if we called it typing_utils that would be better.

I'm the person who suggested utils as a name, and I see your point — typing_utils sounds good to me!

But yeah, this is off-topic for this thread.

[harahu]

(Not clear that it belongs in this PR's discussion, except you alluded that putting it in such a submodule was your intention.)

Yeah, sorry for encouraging continuing the conversation here. I made a comment mentioning this conversation in #45, in order to make the relevant conclusions visible.

[tmke8]

Isn't this basically already covered by the SupportsItems protocol in #45 ?

[harahu]

Isn't this basically already covered by the SupportsItems protocol in #45 ?

This protocol would be a subtype of SupportsItems, but requires more from the implementer than just items, so no.

[JelleZijlstra]

Closing this following the policy to only include things that are in CPython or in a PEP.