<aol> Me too. </aol> Martin > > > "Phillip J. Eby" <pje@telecommunity.com> writes: > > > > >> I hope to have some cycles soon to work on such a framework, but sin= ce > > >> 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. > > > > From: Martin v. LÂöwis [mailto:martin@v.loewis.de] > > > 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. > > > [Paul Moore] > > 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 inter= est > > 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.] > > Well said.
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