> Actually, why not put up a web page of "upcoming changes" somewhere, that > lists major decisions with user impact that were taken on python-dev?
I think "what's new" serves this purpose properly. Usually, every time I commit a new feature, I update the what's new file as well. In fact we already have a partial "roadmap" for Python 3.3: http://docs.python.org/dev/whatsnew/3.3.html I'm not sure who else is doing the same though. If we agree that every time a new feature is added we also update the what's new file we can have such a roadmap with relatively no effort. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/3/9 Stefan Behnel <stefan...@behnel.de>: > "Martin v. Löwis", 08.03.2011 23:47: >>>> >>>> I think everything here is as it should be. People who really cared >>>> about forwards compatibility could have known, but factually, most >>>> people don't care enough. Those then learn for the first time that >>>> some feature was deprecated after it is actually removed. They then >>>> ask why it is removed, and somebody will tell them. >>> >>> I was not aware I could turn on deprecation warning for use of the C >>> API. How can I do that? >> >> Not sure that you can. When I said "could have known", I meant "by >> reading the documentation". > > I can confirm that the Cython project was as surprised of the PyCapsule > change in Python 3.2 as (I guess) most other users, and I would claim that > we are a project with one of the highest probabilities of being impacted by > C-API changes. > > Maybe the "what's new" document could at least include a link to the > relevant python-dev discussion/decision, so that fewer people have to ask > back? > > Actually, why not put up a web page of "upcoming changes" somewhere, that > lists major decisions with user impact that were taken on python-dev? > Including a link to the relevant discussion and decision. Often enough, > decisions are taken inside of huge mailing list threads that get off-topic > before someone has "the right idea" and everyone who's still there to listen > agrees. Even for people lurking around on python-dev, it's easy enough to > miss these moments. > > A publicly visible list of those decisions would > > a) make it easier for non-core developers to follow important changes on > python-dev > > b) allow potentially impacted people to bring up their POV more quickly, > e.g. during the alpha cycle of a deprecation release rather than the > following release, as in this case > > c) document the decision taking process by listing the relevant mailing list > threads > > d) help in writing the "what's new" documents > > Stefan > > _______________________________________________ > 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/g.rodola%40gmail.com > _______________________________________________ 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