On Mon, Dec 10, 2012 at 3:27 AM, Stephen J. Turnbull <step...@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.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com