[Armin Rigo] > Just asking because I'm not sure about this rule: is it ok if I just > make a check-in without first posting a SF bug or patch report for > small bugs with an obvious solution ? Even large bugs. The question is much more whether it's likely that the change will be controversial. If you're an expert in an area, and want to fix what's obviously a bug, without introducing another bug in the process, and in a way that's obviously an improvement, it's not going to be controversial, and everyone saves time and effort if you just do it. Some of those "obviously"s may be obvious only *to* an expert in the area, but that's OK too -- the non-experts in the area wouldn't follow a report or discussion anyway. > In this case: > > >>> import heapq > >>> heapq.heappop(5) > Segmentation fault It depends on what you do. If, for example, you created a new standard SegfaultError exception, and used a platform-specific memory protection gimmick to raise that instead on your box but not others, you could reasonably expect that to be a controversial change on at least two counts. Then you should bring it up for discussion before doing it. If instead you want to say that, in this context, an integer N should act the same way as range(N) would have acted, and have heappop return 0, then you'd be judged insane if you checked that in, and I'd probably revoke your checkin privileges for your own good <wink>. If you want to raise TypeError in this case, great, just do it.
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