Before seeing this issue and its closed status, I created PR 14432, which adds `__length_hint__()` to the iterator returned by builtin `map`.

This PR differs from the original 2017 PR by MSeifert in that the code can distinguish between the cases where a length hint (or length) function is not available, versus a case in which the `__length_hint__()` method of the user-supplied iterable raises an exception.

That is, the new PR propagates exceptions (other than TypeError, per PEP 424) raised in the `__length_hint__()` functions of the user-supplied iterators.

I've read the comments in this issue, and the notes in `test_iterlen.py`:

> [Other] iterators [...], such as enumerate and the other itertools,
> are not length transparent because they have no way to distinguish between
> iterables that report static length and iterators whose length changes with
> each call (i.e. the difference between enumerate('abc') and
> enumerate(iter('abc')).

Can anyone provide a concrete example that illustrates the inherent difficulties of computing a length hint for `map`?  

In ad-hoc testing, the current PR handles situations listed there, and I haven't come across some fundamental show-stopper problem.

There are two limitations to the current PR:

1.  The case where a single iterator is supplied as multiple arguments to `map`, as pointed out by MSeifert:  
    it = iter([1,2,3,4])
    map_it = map(f, it, it)  
2.  When a user-supplied `__length_hint__()` method returns a non-integer, it results in a TypeError in an *inner* evaluation of `PyObject_LengthHint()` (per PEP 424).  When this exception reaches an *outer* evaluation of `PyObject_LengthHint()`, it is cleared (per PEP 424), and leads to operator.length_hint's default value being returned.

If we consider issue 2 to be incorrect,  I think I could fix it by raising RuntimeError from the original TypeError, or by somewhat invasive refactoring of `PyObject_LengthHint()` (which I do not recommend).