>
> So I do not have extensive experience with mypy but I don't see how it
> would help.  The entire issue that is that `str` is an instance of
> `Iterable[str]` so how is mypy going to catch my error of passing a single
> string instead of an iterable of strings to a function?
>
> ...
>
> I like the idea of an `AtomicString` but it doesn't really help unless IO
> and string literals return `AtomicString` instead of `str` (which is just
> as breaking as changing `str`).
>

Is there a reason mypy could not assume that all AtomicStr methods that
return strings actually return an AtomicStr, without impacting runtime
behavior...? Maybe it's not possible and I'm just not familiar enough with
the behavior of the type checkers.

I agree that noisy is broken and that a warning that never becomes an error
> is probably a bad idea.
>
> While I am firmly in the camp that this is a problem I am not sure if its
> a problem that should be fixed.  Any solution will break code, there is no
> way around it. However, I think one possible solution (that has it own set
> of draw backs) would be to simply not register `str` as subclass of
> `Iterable`.  This would allow for the following pattern:
>
> ```
> if isinstance(obj, Iterable):
>   # iterable case
> else:
>   # scalar case
> ```
>
> Where currently the following is required:
>
> ```
> if isinstance(obj, Iterable) and not isinstance(obj, (str, bytes)):
>   # iterable case
> else:
>   # scalar case
> ```
>
> Yes this would break code, but it would break a lot less code than
> actually changing the behavior of `str`.
>

In practice this would be a very odd decision given that the definition of
Iterable is "has an __iter__". And there are plenty of times people will
find the resulting behavior surprising since str DOES have an __iter__
method and there are plenty of times you might want to iterate on sequences
and strs in the same context.

But on the surface at least this seems like it could be much easier to
implement than all the AtomicStr stuff. Of course you are correct it will
break statically typed code, but that really seems like a much easier pill
to swallow than breaking runtime code. I think it's an idea worth exploring.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DSEK7N5TKFMAS5HQKCZDR6QHVBTYJO4V/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to