Chewing international (unicode) filenames on windows?

[Neil Hodgson]

Mark Hammond:
> >    There is also a lot that should be shared, such as the docstrings,
much
> > of the argument parsing as well as many of the posix calls. Splitting
may
> > lead to more breakage when common patches aren't applied to both.
>
> How about just using #include files here then?

   I'm sure some good form of packaging is possible, but as this is a large
and important module, I feel it needs quite a bit of thought and effort to
get right.

> >  It needs a way to specify the base generic
> > posix case cleanly but then to allow platforms to specialise or remove
those
> > functions needing different implementations or which can not be
implemented.
> > In my own C++ work, I normally do this through subclassing.
>
> It doesn't have to be *too* cleanly :)  Having little helper functions
> isn't too bad and could probably work - ie, think "pragmatically" more
> than "cleanly" :)

   I may be in an over-design mode but I've seen large modules (posixmodule
is 150K of fairly dense code) go bad through poor redesign before.

   What is apparent in reading through this code is that there are some
fairly repetitive code patterns. You have a posix function, so it gets a doc
string, some 'HAVE_*' protection, a method table def, and a function. In the
function, the arguments are parsed, the system call is made with threads
turned on, then any error status is turned into an exception and the return
value is boxed. Any allocations are cleaned up. This tickles the commonality
seeker in my brain. The code tries to merge some common sequences with
posix_1str and posix_2str but even this has been complexified by my patch.

   BTW, I'm not volunteering to redesign posixmodule. My original change was
just to allow the file constructor to take a Unicode string which is to me
the biggest gain in functionality.

   Neil