On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin <brian.cur...@gmail.com> wrote: >> >> There are many API changes and proposals that were forgotten and >> didn't get into Python 3, although they should be, because it was the >> only chance to change things with backwards compatibility break. For >> example http://bugs.python.org/issue1559549 > > That can be added in 3.3. > To answer your comment on the issue: no investigation is needed. It didn't > make it in yet because there was no code written for it. It's really not a > big deal, it happens all the time.
Don't you think that if more people were aware of this issue, the patch could be made faster? >> This happened, because of poor bug management, where community doesn't >> play any role in determining which issues are desired. > > The community absolutely plays a role in determining which issues are > desired. They do this by action when they want something. A patch says a > whole lot about desire. > Don't you think that if people could review issues and "star" them then such minor issues could be scheduled for release not only by "severity" status as decided be release manager and several core developers, but also by community vote? Patch requires time, experience and approved contribution agreement, which you've sent using ground mail beforehand. Voting doesn't require any of this, but helps core developers see what user community wants. With the list of desired features Jesse Noller sponsored sprints will have more value for all of us. >> >> This mostly because of limitation of our tracker and desire of people >> to extend it to get damn "stars", module split, sorting, digging and >> tagging options. > > I have no idea what any of this means. Stars: go http://code.google.com/p/support/issues/list find Stars column guess Module split: try to get all issues for 'os' module try to subscribe to all commits for 'CGIHTTPServer' Sorting: click on column titles in bug tracker search results Tagging: as a tracker user, try to add tag 'easy' to some easy issue >> >> I won't be surprised if things won't change in the next couple of >> years, that's why I'd like to propose a very small change, so that >> when time will come to create Python4 (and standard library won't be >> separated from interpreter by this time), everybody can get quickly >> get a list of proposed API enhancements and filter which are eligible >> for the next BC API break. This change is a simple "api-refactoring" >> flag that could be added to corresponding issues by tracker users. > > I'm not sure I see the need for such a flag, as there are probably too few > cases for this in the first place. I haven't started using Python 3 yet, but I already know some annoying API issues that are not fixed there. Unfortunately, I don't remember them to give you a list. That's why I asked for a flag. -- anatoly t. _______________________________________________ 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
