[Python-Dev] test_pep277 vs Win98

[Tim Peters]

[martin@v.loewis.de]
> ...
> There is an abstract underlying capability "supports arbitrary Unicode
> file names"; the test more specifically relies on the capability
> "supports those 8 file names being tested".
>
> I doubt that this should be given a name at all, be it OS neutral or
> not. Whatever name you give it, it is likely that the capability will
> vary across systems, If you take a strict interpretation, you will
> find that no system supports it (e.g. Windows doesn't allow \ in a
> file name); if you take a loser definition, you find that all systems
> support it.

> ...
> It is really hard to find a precise name, but whatever the answer, it
> likely contains the words "unicode" and "file (name)".

This seems too much logic-chopping to me.  Python supports unbounded ints
too, although they're not really unbounded, and it's impossible to say
exactly how unbounded they are across platforms -- or even on one platform.
"Unbounded ints" remains a helpful description regardless.  I'm an expert on
such things, so I *could* quibble about "unbounded ints" endlessly, but it's
not helpful to do so.

Define os.path.supports_unicode_filenames as "supports the 8 specific
filenames tested by test_pep277.py", and then that's a precisely defined
lower bound that should have nothing to do with Windows specifically.  After
all, there is no Windows-specific code in this test!  A platform supports
what this test tries to do, or it doesn't.  If it does, fine, then by
definition it supports_unicode_filenames, and that's what the TestSkipped
logic can test for.

If this is thought to be a particularly stressful set of 8 specific file
names (I can't guess -- "ascii" is the only one I can read <wink>), then
change the set of file names to a more reasonable one.  test_long.py doesn't
try to create billion-digit integers, rather it restricts itself to
"unbounded ints" that any *reasonable* platform can handle.  Do likewise for
Unicode filename support?