As far as your goal is concerned, couldn't you live with a branch where you develop the feature?
That still doesn't help the change getting merged into the trunk. Whether you store it in a patch file, in a DVCS, or in the very same VCS-but-different-branch - these are all minor details, which may affect the efficiency of producing and technically integrating the patch. It doesn't help to the least in speeding up reviews of the patch, or reduces the amount of work necessary to do a review.
For that, all that the contributor can do is to make the contribution review-friendly (make the patch technically complete, separate independent issues, provide a concise, but explicit description, and possibly a guide through the patch); I think Victor could still improve his patches in this respect (and I do understand the difficulties of the language barrier). For me, as a reviewer, a patch is either obvious, correct, and complete at first sight - or it is difficult. I can review only one difficult patch per week (currently), and that can easily cause patches that I need to review to stay in the tracker many months. Of course, there are more active reviewers, so the acceptance rate is higher; OTOH, many committers don't review at all, or shy away from difficult patches.
Actually, I'd like such a branch, too, where I could move much quicker and in particular with the backing of a VCS to port Python to MS Windows CE. Currently, I'm tempted to pull the code into a private repository, which causes problems when I want to push it back upstream.
[I guess you aren't happy with the DVCS systems, such as bazaar, which supposedly work perfect in exactly this case. I won't blame you for that, but still, consider trying out one of them for this project]
We can setup such a branch, unless you reconsider and try bazaar first. There wouldn't be any pushing it back upstream, though - you would still need to go through the tracker for all changes. The only advantage I can see is that it simplifies repeated merging of the trunk into your branch.