[Python-Dev] Keyword meanings [was: Accept just PEP-0426]

[PJ Eby]

On Mon, Dec 10, 2012 at 3:27 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> PJ Eby writes:
>
>  > By "clear", I mean "free of prior assumptions".
>
> Ah, well, I guess I've just run into a personal limitation.  I can't
> imagine thinking that is "free of prior assumptions".  Not my
> own<wink/>, and not by others, either.

I suppose I should have said, "free of *known* prior assumptions",
since the trick to suspending assumptions is to find the ones you
*have*.

The deeper assumptions, alas, can usually only be found by clashing
opinions with others...  then stepping back and going, "wait...  what
does he/she believe that's *different* from what I believe, that
allows them to have that differing opinion?"

And then that's how you find out what it is that *you're* assuming,
that you didn't know you were assuming.  ;-)  (Not to mention what the
other person is.)


>  > Put together, the phrase "clear thinking on concrete use cases" means
>  > (at least to me), "dropping all preconceptions of the existing design
>  > and starting over from square one, to ask how best the problem may be
>  > solved, using specific examples as a guide rather than using
>  > generalities."
>
> Sure, but ISTM that's the opposite of what you've actually been doing,
> at least in terms of contributing to my understanding.  One obstacle
> to discussion you have contributed to overcoming in my thinking is the
> big generality that the packager (ie, the person writing the metadata)
> is in a position to recommend "good behavior" to the installation
> tool, vs. being in a position to point out "relevant considerations"
> for users and tools installing the packager's product.

Right, but I started from a concrete scenario I wanted to avoid, which
led me to question the assumption that those fields were actually
useful.  As soon as I began questioning *that* assumption and asking
for use cases (2 years ago, in the last PEP 345 revision discussion),
it became apparent to me that there was something seriously wrong with
the conflicts and obsoletes fields, as they had almost no real utility
as they were defined and understood at that point.

> Until that generality is formulated and expressed, it's very difficult
> to see why the examples and particular solutions to use cases that
> various proponents have described fail to address some real problems.

Unfortunately, it's a chicken-and-egg problem: until you know what
assumptions are being made, you can't formulate them.  It's an
iterative process of exposing assumptions, until you succeed in
actually communicating.  ;-)

Heck, even something as simple as my assumptions about what "clear
thinking" meant and what I was trying to say has taken some back and
forth to clarify.  ;-)

> It was difficult for me to see, at first, what distinction was
> actually being made.
>
> Specifically, I thought that the question about "Obsoletes" vs.
> "Obsoleted-By" was about which package should be considered
> authoritative about obsolescence.  That is a reasonable distinction
> for that particular discussion, but there is a deeper, and general,
> principle behind that.  Namely, "metadata is descriptive, not
> prescriptive."

Actually, the principle I was clinging to for *both* fields was not
giving project authors authority over other people's projects.  It's
fine for metadata to be prescriptive (e.g. requirements), it's just
that it should be prescriptive *only* for that project in isolation.
(In the broader sense, it also applies to the distro situation: the
project author doesn't really have authority over the distro, either,
so it can only be a suggestion there, as well.)