An interesting pytype experiment, and a possible extension to strings

Ideas
8

It’s not really “strict-strings”. Its more like “atomic strings”: treating strings as atomic, not as “strict”.

If type checkers can accept a flag to reject strings from Collections, Iterables etc isn’t that type negation? The only difference is that the set of types being negated is hard-coded to str alone.

So it seems to me that the type checkers would have to implement type negation, but artificially limited to a single type.

Having atomic strings at runtime is a frequently desired feature. Here’s a radical suggestion for people to shoot down:

  • Introduce a new abstract type, “basestr” which implements all the string functionality except for iteration etc.

  • Subclass that as a new builtin, “atomicstr”, with “a-string” syntax: s = a"spam eggs and spam" would be an atomic string.

  • Atomic strings don’t just type-check as atomic but behave as atomic at runtime as well.

  • Regular str inherits from basestr, and adds back in iteration etc.

Disadvantages:

  • There’s a bit of work needed to rearrange the string implementation, but it is mostly refactoring, and a one-off cost.

  • Two new builtin names.

  • One more string prefix.

  • str methods will have a teeny bit more overhead. But that should be negligible.

  • Can’t be ported back to older Pythons.

Advantages:

  • Easy for both static and runtime type checks to specify that you want atomic strings, regular strings, or both.

  • Type checkers don’t have to implement anything special. atomicstr and str are different types.

  • Dealing with strings as atomic non-iterable objects becomes much easier for everybody, not just users of type hints.

  • No need for the meaning of type hints to depend on a non-obvious global flag.

  • Fully backwards compatible.

2 Likes