Glyph Lefkowitz wrote:
Still, it would have been more helpful to point out how exactly this
problem could be solved, and to present (for example) a description of
similar objects politely interacting and delegating responsibility to
one another to accomplish the same task.
Sorry, I edited out the bit at the last minute where I explained that it would
be great to have a centralized option-managing object such that any command can
ask what options were set on any other regardless of the dependencies between
commands.
I would definitely characterize these assertion from Robert as
"nebulous", given that the prior messages in the thread (as far as I can
tell) do not describe the kind of massive-overhaul changes which would
fix things, only the problems that currently exist:
In our considered opinion, piecemeal changes probably aren't going to
solve the significant problems that we face.
Why not? The whole of computer history is the story of piecemeal
improvements of one kind or another; despite perennial claims that, for
example, hierarchical filesystems or bit-mapped displays "fundamentally"
cannot support one type of data or another, here we are.
Perhaps in my head the analogy with biological evolution is unjustifiably
strong. Species can't always get from point A to point B while making viable
intermediates with incremental changes. Evolutionary deadends happen frequently.
In software, design decisions early on affect how much change the software can
tolerate (which is why we are told to "design for change"). I think that
distutils exemplifies a design that is particularly adverse to evolution.
Or this one, also from Robert:
Mostly because I'm entirely uninterested in helping you make
incremental improvements that are going to break all the hard work
we've already done just to get things working as it is.
Why do incremental improvements have to break all the hard work that has
already been done? Surely this is what a compatibility policy is about.
Since Tarek keeps asking us to make proposals without thinking about
compatibility, I wonder what policy is being kept in mind. My comment stems from
my worry about that attitude.
In any case, I think that keeping compatibility while making improvements to the
code in situ is going to be quite difficult. The distutils API is not clean.
Using distutils beyond setup() and Extension() involves too much intimate
knowledge of the detailed implementation of distutils as-is. That's why we got a
2.6.4 release.
This is why I think the piecemeal evolution of distutils is not going to work.
The act of fixing distutils to make a cleaner API for modification and extension
*triggers* the problem that the fix is supposed to address.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
