Add __new__ to str and int stubs in both Pythons.

[sproshev]

No description provided.

[JelleZijlstra]

What concrete problem does this solve? I'm hesitant to change stubs as basic as these without a clear justification.

[JelleZijlstra]

All defaults should be ....

[sproshev]

We have the issue https://youtrack.jetbrains.com/issue/PY-23540 where we raise a warning on return str.__new__( cls, *args, **kwargs ) line.

[sproshev]

Not sure how to fix compatibility issue inside IntEnum :(

[JelleZijlstra]

Thanks, that makes sense. mypy also gives a spurious error on calling int.__new__(int, '3', 10).

I don't have a great solution for the test failures either. We could # type: ignore them away, but I think mypy's parser won't accept that.

[sproshev]

Fixed!

[JelleZijlstra]

Yes, this seems to work. I tested it on my codebase too and got no errors. I'll leave this open a few more days in case other maintainers have concerns, then merge it.

[gvanrossum]

Hm, mypy on the issue from the PyCharm tracker reports this, both with and without the change:

__tmp__.py:19: error: Inconsistent metaclass structure for 'MyString'
__tmp__.py:24: error: Name 'spam' is not defined
__tmp__.py:24: error: "MyString" expects no type arguments, but 1 given

Other than that, no much difference. (Though I wonder what would happen if someone were to add SupportsInt as a base class to str, or when PEP 544 (duck typing) is introduced.