Maybe, but that subset aren’t well defined proposals, so they’re not really discussion material as alternative syntaxes.
Part of the reason that nobody’s seriously suggested a future import for this is that it’s something that is better to introduce in parallel. Late binding would be less efficient than early binding, and doesn’t work as well with certain types of introspection, so it would be best to allow a function to be written with a mix of early and late bound defaults as needed. Since there’s good reason to keep early binding around forever, it’s better to devise a new syntax for late binding, thus ensuring that existing code retains its semantics. For example:
def func(stuff=>[], mode=constants.MODE_NORMAL): ...
would have one late-bound argument and one early-bound, with the value of constants.MODE_NORMAL being retained, but the code of constructing a new list being prepended to the function.
While it would be reasonable and sane to have a language with nothing but late-bound defaults, changing Python to this would likely cause extremely subtle problems with people’s code (since the vast majority of functions will behave identically in both forms), so as backward-compatibility breaches go, this would be a pretty nasty one. At the point at which the future directive becomes the default, there would be bizarre phenomena where the behaviour of a function changes very slightly across Python versions, with no apparent reason.