Add single configuration option to retain various old behaviors

[JukkaL]

Every once in a while we change something in mypy that breaks backward compatibility, and this can make it hard for owners of large codebases to migrate to a new mypy version. A related issue is that some changes that we'd like to make would cause so much work for existing users that we decide to postpone the change indefinitely (see #5392 as an example).

What if we'd adopt a policy of retaining the old behaviors through a configuration option, whenever there is a lot of expected breakage? This way existing users could just continue to use the old behavior without having to migrate their code, while new users would automatically get the new (and improved, I'd hope) behavior.

A potential drawback would be the introduction of many additional options for legacy behaviors that are only of interest to a small subset of users. My solution to this is to enable all of the behaviors with a single option.

Let's use #5392 as an example. The change would cause some if/else expression to return a union type instead of a join. We could enable the old behavior through --backward-compat if-else (the option name needs more thought). The value of the option would be a comma-separated list of legacy behaviors.

Another candidate for this feature is #5401.

Pros:

• Migration to new mypy versions will be easier for users with lots of code.
• Breaking changes are easier to justify, since we can provide a fallback for existing users.
• Backward compatibility features are behind a single option which can be easily ignored by users that don't care about it.
• If the compatibility options are per-module, migration to new semantics can be performed gradually.

Cons:

• Some users may be unaware of the option and be reluctant to upgrade to new mypy versions because of the migration work they believe to be necessary.
• Supporting multiple additional options may decrease maintainability of mypy and result in bugs and weird corner cases.
• We may never be able to deprecate some old behaviors.

[gvanrossum]

Nice idea. I worry that some teams will just turn on the backwards compatibility option for everything and never clean up, essentially living in the past forever. This is already our experience with strict-optional (mostly).

[ethanhs]

If we go ahead with this, it would be nice to make these per-module. While people have just fallen back to using --no-strict-optional, I have seen people make it per-module (I think we do this for one module), so it provides a path to gradually move away from the old behavior (which is the eventual goal I hope).

[JukkaL]

I worry that some teams will just turn on the backwards compatibility option for everything and never clean up, essentially living in the past forever.

I expect that this will happen for some larger projects. Migrating smaller projects (say, under 50k lines) will likely be easy enough, most of the time, so that they won't have a real need to use these options. I think that it's acceptable that some teams are stuck with the compatibility options. The majority of users should be using the new semantics after a while, especially if our user population continues to grow. New users have no need to use the legacy options.

If we go ahead with this, it would be nice to make these per-module.

Agreed, unless a particular feature is difficult to support as a per-module option.

[gvanrossum]

OK. Thumbs up for the plan.

On Tue, Jul 31, 2018 at 4:02 AM Jukka Lehtosalo ***@***.***> wrote: I worry that some teams will just turn on the backwards compatibility option for everything and never clean up, essentially living in the past forever. I expect that this will happen for some larger projects. Migrating smaller projects (say, under 50k lines) will likely be easy enough, most of the time, so that they won't have a real need to use these options. I think that it's acceptable that some teams are stuck with the compatibility options. The majority of users should be using the new semantics after a while, especially if our user population continues to grow. New users have no need to use the legacy options. If we go ahead with this, it would be nice to make these per-module. Agreed, unless a particular feature is difficult to support as a per-module option. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5403 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACwrMoxW9hUmVfKusEJ3aWjeTzm_lAPTks5uMDligaJpZM4VmSuI> .

-- --Guido (mobile)

[ilevkivskyi]

I also like the idea, many projects already rely on mypy even though it is still beta. It is good to provide a way to avoid breaking some code in situations where a trade-off decisions are involved.