> So It is better to define what a "public function" is.
That is no easy task.  See #10894 for a general discussion.  For the particular case of distutils, there is no distinction between internal helpers that we should be free to change and public functions provided to third-party code.  That’s one of the reasons we had to fork under a new name to have a chance to clean things up (i.e. make nearly everything private).

> If new people get involved in distutils development they will need to
> read all the code, line by line and every comment, because the old
> developers decided not to document the inner workings of its functions.
A lot of people have bee learning distutils internals in recent years: Tarek, the current maintainer; hackers from Montreal; Google Summer of Code students like me.  So it is possible to get involved with distutils, starting with one area (network code, or versions and dependencies, or commands, or compilers...).  That said, I agree the doc is very lacking, and improving it is one of my big goals for distutils2 in Python 3.3.  (I will give priority to important user-facing functions and classes over helpers like mkpath, however.)

> Well, I know nothing about this. However, if you tell me that
> distutils2 will replace distutils, I may agree with you and distutils
> just needs to be deprecated. Otherwise, I keep my opinion.
distutils is frozen and only gets bug fixes; distutils2 is a fork where we can break compatibility to fix the design and behavior.  More information on http://tarekziade.wordpress.com/2010/03/03/the-fate-of-distutils-pycon-summit-packaging-sprint-detailed-report/

I am now closing this issue.  If I have misunderstood your last message and you’re not satisfied with that, please reopen.  Thanks again for your report, and don’t hesitate to report any bug you may find in the future.