Python Refactoring – Should a Python Class with Many Methods Be Split into Multiple Classes?

Sounds like a case for using extension methods. Simply move Function1() to MyViewModelHelper, make it static, and change the first/only paramater to be like this:

public static class MyViewModelHelper
{
    public static void Function1(this ViewModel vm)
    {
        // whatever
    }
}

As a benefit: afterward, the semantics of the callers often don't need to change.

It's fine. It's fine in C++ as well, for reference.

Keeping tightly-coupled things together is sensible practice. Avoiding inappropriate coupling is also good practice. Striking the right balance isn't a matter of strict rules, but of, well, striking a balance between different concerns.

Some rules of thumb:

1. Size

   Excessively large files can be ugly, but that's hardly the case here. Ugliness is probably a good enough reason to split a file, but developing that aesthetic sense is largely a matter of experience, so it doesn't help you figure out what to do a priori

2. Separation of Concerns

   If your concrete implementations have very different internal concerns, your single file accumulates all those concerns. For example, implementations with non-overlapping dependencies make your single file depend on the union of all those dependencies.

   So, it might sometimes be reasonable to consider the sub-classes' coupling to their dependencies outweighs their coupling to the interface (or conversely, the concern of implementing an interface is weaker than the concerns internal to that implementation).

   As a specific example, take a generic database interface. Concrete implementations using an in-memory DB, an SQL RDBMS and a web query respectively may have nothing in common apart from the interface, and forcing everyone who wants the lightweight in-memory version to also import an SQL library is nasty.

3. Encapsulation

   Although you can write well-encapsulated classes in the same module, it could encourage unnecessary coupling just because you have access to implementation details that wouldn't otherwise be exported outside the module.

   This is just poor style I think, but you could enforce better discipline by splitting the module if you really can't break the habit.