[Python-Dev] Keyword meanings [was: Accept just PEP-0426] (original) (raw)

PJ Eby pje at telecommunity.com
Mon Dec 10 17:34:58 CET 2012

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, 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.)

More information about the Python-Dev mailing list