On Nov 12, 2009, at 1:36 AM, Robert Kern wrote: > Glyph Lefkowitz wrote: > >> Still, it would have been more helpful to point out how exactly this problem >> could be solved, (...)
> 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'm familiar with the hazards of over-editing :). I am often asked to shorten my messages, and when I try too hard to do so, I leave out important elements. One of the things I'm asking for, actually, is fewer, longer messages, with more substantive points in them. I know some people don't like that, but discussions about big, complex topics like this that try to address them one little conversational point at a time tend to get circular quickly. > 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. This is explicitly _not_ biological evolution. For example, when you wonder about this: > 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. The way I'm interpreting Tarek's comments - and he can correct me if I'm wrong - is that the strategy is to short-circuit evolution. We should decide where we want to go - which may be an apparently discontinuous place - then path-find there. The path-finding is rarely as hard as it seems like it's going to be. The brute-force approach, which also happens to be an approximation of the Twisted framework compatibility baseline, is: release -1: import old; old.crummy_api() release 0: old.crummy_api() emits a PendingDeprecationWarning, new.good_api() introduced release 1: old.crummy_api emits DeprecationWarning pointing at new.good_api(), new.good_api() improved based on feedback from r0 release 2: old.crummy_api raises DeprecationError pointing at new.good_api() release 3: old.crummy_api removed This is almost a straw-man: you can do this for any old.crummy_api and new.good_api, regardless of whether the new thing actually satisfies the old thing's requirements at all. It is often possible to do much better. But the point is, if you have a clear new.good_api to get to, it's possible to do all *kinds* of crazy stuff in Python to emulate and re-direct the behavior of crummy_api, discover how it's being used, provide useful hints to the developer, etc. It's a matter of how much effort you want to put into it. For many distutils use-cases, it sounds to me like the path forward is to avoid using any API at all, and just ask most projects to provide static metadata. Build-heavy projects like numpy will require new integration points to do custom heavy lifting, but it will be easier to define those integration points if they're not something that every project under the sun will potentially need to interact with. But, during the creative design process of good_api, it's often helpful to pretend crummy_api doesn't even exist, so you can design something good that solves its problems well, and address the translation as a truly separate issue. > In software, design decisions early on affect how much change the software > can tolerate (which is why we are told to "design for change"). Who's "we", kimosabe? *We* are told "you aren't gonna need it"; maybe some other people are told to design for change :). In fact, I think that distutils is over-designed for change. It has altogether too many different extension mechanisms, which often interfere with each other: subclassing, configuration files, including random bits of code in setup.py. And then of course there's the monkey-patching for the cases that weren't covered :). _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
