Accepting an iterable of strings, but NOT a plain string#2028

Unanswered

Dr-Irv asked this question inQ&A

Dr-Irv

Jun 17, 2025

· 2 comments· 3 replies

Return to top

Discussion options

Dr-Irv
Jun 17, 2025

Inpandas, we have methods that can accept iterables of strings, but not a plain string. Fromuseful_types, there is theSequenceNotStr type that is a sequence that doesn't include plain strings. But how can we do the same for iterables? I thought of doing something like this:

Example:

fromtypingimportIterable,overload,NoReturn@overloaddeffunc(s:str)->NoReturn: ...@overloaddeffunc(s:Iterable[str])->list[str]: ...deffunc(s:Iterable[str])->list[str]:ifisinstance(s,str):raiseException("plain string not accepted")else:x= [vforvins]returnx# reveal_type(func("abc"))func("abc")v=3+4func({"a":1,"b":2})

This code will raise an exception as expected. If I uncomment thereveal_type() line, the type is revealed asNoReturn orNever by pyright and mypy, respectively. Butpyright andmypy don't say that the line withv = 3 + 4 is unreachable.

Ideally, the type checker would show thatfunc("abc") is an invalid call. How do we accomplish that?

You must be logged in to vote

Replies: 2 comments 3 replies

Comment options

brianschubert
Jun 17, 2025

Linking#256 for related discussion

You must be logged in to vote

0 replies

Comment options

randolf-scholz
Jun 18, 2025

But pyright and mypy don't say that the line with v = 3 + 4 is unreachable.

I think this may be a configuration issue.mypy-playground,pyright-playground

One caveat is that they only raise the unreachable on the next line, not on the line that produces theNever, which can lead to subtle false negatives. For example, if you have areturn func("abc") in the last line of some function.

See:python/mypy#15821

You must be logged in to vote

3 replies

Comment options

Dr-Irv Jun 18, 2025
Author

I think this may be a configuration issue.

Yes, forpyright it is, and that's a new parameter as of a week ago. IMHO, the result ofNoReturn in a case like this should be flagged differently. It should be "that's an invalid call". It's not about reachability - it's that you passed an incorrect parameter and the code will never return.

Take this simple example:

deffoo()->NoReturn:raiseNotImplementedErrorfoo()

Shouldn't the type checker say thatfoo() is problematic because it has a result ofNoReturn. (Note: I realize this might be the topic of a different discussion).

Comment options

erictraut Jun 18, 2025
Collaborator

A function signature with aNoReturn return type doesn't mean that the call is invalid. It means that it's valid but control will not return to the caller after the call. Refer tothis section of the typing spec for details.

What you're looking for is a way to mark the overload as an error condition, which would require a new mechanism and an update to the existingoverload call evaluation specification. There has beensome discussion of this previously, but no one has driven a concrete proposal.