Backwards emulation rather than backwards compatibility?

[Neil Hodgson]

John Roth:
> "Neil Hodgson" <nhodgson at bigpond.net.au> wrote in message
> > Or a 1.52 module asked to deal with
> > Unicode?
>
> It would probably fail, since 1.5.2 doesn't support Unicode. Of course,
> there are some methods on a unicode string (such as __len__) that
> would work, but in general, if the method didn't exist, why is the old
> code calling it?

   Because it was handed an argument and the assumptions it makes for that
argument are that it is of a type that support the operations the old code
will apply to the argument. In the current situation with one language level
used, much code is unconcerned by actual types and gets by with relying on
which methods are present. When I added some support for Unicode file names,
much code including glob, worked quite well even though it was not expecting
Unicode.

   With your multiple level concept, the exact semantics that you desire
from passing Unicode objects between levels has to be defined. One technique
is to say that since level 1.52 does not support Unicode, then they must be
converted to narrow strings by cross level marshalling code. Another
approach would be to say that they are treated as objects of a user defined
class by the 1.52 level code.

   Interesting questions involving levels include whether operations are
completely determined by the lexical (module) context they are executed in
or by the home context where the object was created.

   Neil