Thomas Wouters wrote: > Unfortunately, that's not how it works :-) If you check something into > the trunk, it will be merged into Py3k sooner or later. I may ask the > original submitter for assistance if it's incredibly hard to figure out > the changes, but so far, I only had to do that with the SSL changes. The > decimal changes are being merged as I write this (tests running now.) Is > there anything in particular that needs to be done for decimal in Py3k, > besides renaming __div__ to __truediv__? > > If you re-eally need to check something into the trunk that re-eally > must not be merged into py3k, but you're afraid it's not going to be > obvious to the merger, please record the change as 'merged' using > "svnmerge merge -M -r<revision>". Please take care when picking the > revision ;) You can also just email me or someone else you see doing > merges, as I doubt this will be a common occurance.
I'm getting ready to port my PEP 3101 implementation (str.format() and friends) from py3k back to 2.6. How do I make it obvious that this is something that doesn't need to be ported to py3k? I'm not sure what "obvious to the merger" means. Is a "backported" checkin comment good enough? With any luck this will be done with a single checkin to the trunk, and another checkin to py3k so that the implementations can remain identical. I just want to make sure I don't make life more difficult than necessary for the folks doing the very valuable merge process. Eric. _______________________________________________ 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
