With more special cases, sure.
> 2. use case: I assume this is the efficiency argument in
> a new guise?
No. It does explain the inefficiency, though.
> 3. grammar: if there were an obvious choice, this discussion
> would have ceased long ago: ``tile`` is as good as any for
> this reason,
I'm not referring to the names. ones()/zeros()/empty() are designed and documented for similar use cases. You describe them in very similar ways: "in order to make an array of a given shape and dtype filled with (1s/0s/nothing in particular), use ones()/zeros()/empty()". You should never describe tile() with a similar sentence. It happens to do something similar given a very specific corner case, but that is not what the function does and that is not what it is for.
> and I don't see the problem with ``tile_like``.
It makes no sense except in the scalar case.
> 4. isolated idiom (i.e., 3. again): the only way around this
> is to use ``constant``, which is in use in other languages.
> This has been vetoed as confusing terminology.
> The problems with each other suggestion have been covered
> extensively in this and related threads.
Again, I'm not talking about the name or our relationship to other languages. Abusing tile() for this use case (which is *not* the use case it is designed and documented for) would make it a numpy idiom, just something that you have to be told and remember, much like the current idiom that we recommend:
np.ones(shape) * value
It is the complete API of tile() and the fact that it only happens to meet the use case by abusing a small corner of its API that makes it use for this an idiom. No matter what we name the function in the PR, it won't be an idiom in the way I mean here.
--
Robert Kern