Re: [Docutils-develop] FinalChecks

[David G. <go...@py...>]

[Felix Wiemann]
> So "FinalChecks" is not appropriate anymore.  That's what I'm
> saying.

Fine.  I agree.  I have no issue with the name change.  It's the
*priority* change that I take issue with.

>> Sometimes you split hairs in a most annoying way ;-)
>
> I'm not splitting hairs.

Yes, you are.  I'm talking about the priority of the transforms, and
you keep harping on about the name.  The idea I've been trying to get
across, and that you've been obstinate about, is that the name,
"Final", is a reflection of the priority.  It reinforces the priority.
It should have given you pause before you arbitrarily changed the
priority.

I don't know how much clearer I can make it.

>> Good: please revert your transform changes [rev. 3659] from the
>> trunk, and put them in your "transform" branch.
>
> It causes too many conflicts and failing tests.  That's wasted
> effort, and it would be a regression.  Let's discuss this issue and
> then decide what to do, not blindly revert changes that happened two
> months ago.

If you look back, you'll see that I questioned the change two months
ago.  It should have been reverted then.

> As a matter of fact, I was rather thinking of the
> two-stage-processing feature that should have been put on a branch,

Yes, it should have been.  That was definitely a bad idea, a wrong
idea.  It must be removed.  Will you please do that?

The reason you gave for the revision 3659 split & re-prioritizing was:

    I tried so divide the default transforms into two stages,

So those changes were a direct result of the "two stage" idea.

Repeat until enlightenment:

    There is no "two-stage processing".
    There is only processing.

We will make no compromises for "two-stage processing".  Any
compromises made for this so far were mistaken, and must be removed.
We will make changes to allow a doctree to be processed multiple
times.

> not the FinalChecks refactoring.  I'm absolutely *not* going to
> branch for simple refactorings like this one, especially as long as
> we have review times over two weeks.

We absolutely *are* going to branch for any and all API changes.

The trunk is currently a mess.  You made it that way with your
heavy-handed checkins.  I'm dreading the cleanup that's required.

>> I have neither the time nor the will to check all the transform
>> dependencies to make sure that rearranging them hasn't introduced
>> some kind of problem.
>
> I don't think it has introduced a problem.

Perhaps.  I don't know.  But it wasn't broken before, and you changed
it arbitrarily, on a whim.

If it ain't broke, don't fix it.

It could very well be that there's no problem.  But at this point,
that's not what I care about.  It's just a symptom.  I care about the
"two-stage processing" misfeature that's now in the code, and must be
removed.  And I care about the fact that you check in your ideas too
quickly, without consultation.  If your ideas were universally great,
that would be OK, but this one was really, really bad.

>> I already did that work [checking all dependencies] when creating
>> the transforms in the first place, and I don't want to do it again.
>
> A.k.a. "it's so poorly structured that I cannot easily check whether
> it correct, but it works at the moment, so won't you dare touch it
> because you might break it".  That smells *extremely* bad.

No, that's not what I said nor what I meant, and you know it.  The
interactions between transforms are complex and tricky.  Having
written most of them, I know it very well.  Document tree transforms
are hard, mind-twisting.

Don't twist my words or attempt to put words in my mouth.

> And it indicates that the code is in need of some refactoring.
> Renaming a reference checker from FinalChecks to DanglingReferences
> (compare: which name says more about what the transform actually
> does?)

I don't give a $#!* about the name change.

> and changing its priority so it's executed together with the other
> reference-handling tranforms

*That's* what I care about.

> is clearly a step into the right direction.

No, it is not.  Look, that particular part of the transform was given
that priority *for a reason*.  The fact that I don't recall the
reason, just says that it should have been documented better.  Mea
culpa.  And as I said, it could well be that there is no problem now.
But that's not the point.

The point is, there's no reason to arbitrarily change a working
transform's priority just so that the transform priorities sort
cleaner.  That's simply ridiculous.

> Embrace Change, please.

There's a difference between arbitrary change and progress.  I embrace
progress.  Change for change's sake is *not* progress.

Felix, stop being an ass, and stop wasting my time.
This comment and the one above are offensive.

*****

This weekend I'm going to take the time to review the codebase as it
stands, and the transforms branch.

--
David Goodger <http://python.net/~goodger>