From: Martin v. L=F6wis [mailto:martin@v.loewis.de] > "Phillip J. Eby" <pje@telecommunity.com> writes: >> I hope to have some cycles soon to work on such a framework, but = since >> it effectively depends on both PEP 246 and an unwritten PEP for a >> "protocol declaration API" like the one in PyProtocols, it would be >> good to get some idea of whether the Python developer community feels >> this is a good direction for me to pursue. > I'm quite skeptical about "grand new architectures" whose development > starts off with "what we have is rubbish". In my experience, the > rubbish that we have right now continues to be much better than what > the grand new architecture can deliver for several years to come. So I > would always favour evolution over revolution. To some extent I agree with this. I haven't taken the time to *fully* digest the adaptation PEP or Phillip's protocol ideas, but my general impression is that they hover somewhere on the border. Their proponents describe them as if they were grand new architectures, with an implication of "let's rewrite everything" because "what we have is rubbish" (as you say). But in practice, I can't see anything in either of these proposals which really needs much change to what we currently have. I suspect that the reality is that they are more or less descriptions of "useful patterns" which can be used to offer a standard answer to issues which sometimes come up with current methods, but which aren't frequent or severe enough to justify major angst. (For example, the old one about what precisely constitutes a "file-like" object in a given context). In this context, it's not entirely clear to me why the proposals need "official = sanction", as opposed to simply being made available as user-level libraries, with the possibility of migrating to "standard" status if the level of = interest proves to justify it. As usual, I suspect the reality is somewhere between these two extremes. But I'd like to see the two proposals restated in the form of working library code. Then I could *try* them rather than arguing about theory. [Of course if there really *is* a need for language support, this would focus on the *exact* language change needed, along with a real use case to justify it.] Paul.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4