[Python-Dev] I would like an svn account (original) (raw)

Victor Stinner victor.stinner at haypocalc.com
Wed Dec 31 14:26:58 CET 2008

Le Wednesday 31 December 2008 08:46:09 Stephen J. Turnbull, vous avez écrit :

Would you review your own code in the same way that other committers review their own?

I'm unable to review my own code. I always re-read my code and test it, but I can not see every possibles cases. That's why I prefer external eyes to review my code for parts of the code that I don't understand/known well enough.

Would you make the same decisions about which fixes to commit, which changes to wait for others' review, and which to propose on Python-Dev first?

I think that I'm able to know if a patch needs a review or not. Especially if the patch changes the behaviour or the API (or if the patch is complex), I always prefer a review.

I will not use svn as I use the tracker. Sometimes, I write a quick and dirty patch to demonstrate a feature or to propose a solution to fix the bug. If the solution is accepted, I try to write a better patch.

> The bigger patch was the bytes filename support for Python3, > accepted by Guido (after a long review ;-)).

Would you have committed that patch if nobody else had reviewed it?

Certainly not. The patch changed the behaviour of most functions related to files. The mailing list + the bug tracker were the right tools.

> Just because there are not enough people to review/commit patches > on the tracker and

Are you planning to review and commit other people's patches, and help reduce this backlog? Or just your own?

It depends on the issue. There are many trivial fixes that doesn't change the behaviour / API but just improve the project and are waiting for a review or are reviewed but not commited yet.

About my own patch: yes, I would like to use direclty on the svn without using the tracker to fix trivial bugs. Example: during one month, there were two gcc warnings in _testcapi module. The fix was trivial and it requires too much efforts to open an issue for such stupid warning.

Again, I'm more supportive of people who want commit privileges in part to help improve the project's process, as well as to remove obstacles to their own work.

My not-so-secret goal is also to improve Python stability against fuzzing. I stopped to work on fuzzing because it took sometimes months to fix a dummy bug (dummy : easy to understand but also easy to fix without side effects).

Example of such issue: "import _tkinter; _tkinter.mainloop()" crashs Python (maybe not directly but later on garbage collection). I opened the issue (with a patch) in august, gpolo reviewed the patch ("Looks fine to me.") two weeks later, but 4 months later the isue is still open: http://bugs.python.org/issue3638

Is it was you called "An open issue is not a lost patch."?

An open issue is not a lost patch. It's an open issue. In my own projects, I oppose candidates who seem to think that the presumption is that a patch should be applied quickly unless there's good reason given not to. Your phrasing suggests that attitude to me.

Even after a review, some issues stay open for months or years.

Another example of issue: nntplib doesn't support IPv6, dmorr proposed a simple and good patch reusing the nice function socket.create_connection() one year ago. In this case, I think that nobody was able to test the change. But without testing it, I'm sure that the patch is better than the current situation. Well, if I have to commit the patch, I will test it before. My computer has a public IPv6 address :-) http://bugs.python.org/issue1664

You don't have to pay attention to me,

No, your opinion is interresting. I hope that my answers will help you to understand my expectations about an svn account :-)

-- Victor Stinner aka haypo http://www.haypocalc.com/blog/

More information about the Python-Dev mailing list