> > "Phillip J. Eby" <pje@telecommunity.com> writes: >=20 > >> 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. >=20 > From: Martin v. L=F6wis [mailto:martin@v.loewis.de] > > I'm quite skeptical about "grand new architectures" whose develop= ment > > starts off with "what we have is rubbish". In my experience, the > > rubbish that we have right now continues to be much better than w= hat > > the grand new architecture can deliver for several years to come.= So I > > would always favour evolution over revolution. >=20 [Paul Moore] > To some extent I agree with this. I haven't taken the time to *full= y* > digest the adaptation PEP or Phillip's protocol ideas, but my gener= al > impression is that they hover somewhere on the border. Their propon= ents > 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). >=20 > 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 patte= rns" > which can be used to offer a standard answer to issues which someti= mes > come up with current methods, but which aren't frequent or severe e= nough > to justify major angst. (For example, the old one about what precis= ely > constitutes a "file-like" object in a given context). In this conte= xt, > it's not entirely clear to me why the proposals need "official sanc= tion", > as opposed to simply being made available as user-level libraries, = with > the possibility of migrating to "standard" status if the level of i= nterest > proves to justify it. >=20 > As usual, I suspect the reality is somewhere between these two extr= emes. > But I'd like to see the two proposals restated in the form of worki= ng > library code. Then I could *try* them rather than arguing about the= ory. > [Of course if there really *is* a need for language support, this w= ould > focus on the *exact* language change needed, along with a real use = case > to justify it.] Well said. --Guido van Rossum (home page: http://www.python.org/~guido/)
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