Hi people! After some months, Decimal is now in the trunk again. It's fully updated to the latest Cowlishaw specification, and complying with the latest test cases (from a few days ago, which even take in consideration some feedback from ours). I want to thank so much to Mark Dickinson, who made *a lot* of this work, not only the math part (he's a mathematician himself), but also a lot of cleaning and speeding up. Now we will put our hands in the documentation, for it to be 100% OK way before 2.6 arrives. Py3 will come after that. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On 9/13/07, Facundo Batista <facundobatista@gmail.com> wrote:
Hi people!
After some months, Decimal is now in the trunk again.
It's fully updated to the latest Cowlishaw specification, and complying with the latest test cases (from a few days ago, which even take in consideration some feedback from ours).
I want to thank so much to Mark Dickinson, who made *a lot* of this work, not only the math part (he's a mathematician himself), but also a lot of cleaning and speeding up.
Now we will put our hands in the documentation, for it to be 100% OK way before 2.6 arrives.
Py3 will come after that.
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. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
2007/9/18, Thomas Wouters <thomas@python.org>:
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__?
There isn't nothing really special to do, but my plan was because I didn't know how the mechanism worked, ;) It'd be great if all the changes that I'm making to Decimal are automatically, at some point, merged into Py3k (I guess that using the conversion tool). But at some point, both codes may start to diverge, because Py3k-specific optimizations could be done there... but this could be done in an year or two, ;). So, how is this handled? Until which moment can I expect that the changes in the trunk are merged to Py3k? Thank you very much! Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On 9/19/07, Facundo Batista <facundobatista@gmail.com> wrote:
2007/9/18, Thomas Wouters <thomas@python.org>:
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__?
There isn't nothing really special to do, but my plan was because I didn't know how the mechanism worked, ;)
It'd be great if all the changes that I'm making to Decimal are automatically, at some point, merged into Py3k (I guess that using the conversion tool).
I don't usually have to use the 2to3 tool, but sometimes, yes. But at some point, both codes may start to diverge, because
Py3k-specific optimizations could be done there... but this could be done in an year or two, ;).
So, how is this handled? Until which moment can I expect that the changes in the trunk are merged to Py3k?
Until you hear otherwise :) You can commit py3k-specific changes to the py3k branch, the merges shouldn't lose them. (Of course, mistakes in merging are possible, which is why tests are good :) If I do base the merge on the 2to3 outpt of the trunk version, I'd be careful not to lose changes made in the branch. -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
2007/9/19, Thomas Wouters <thomas@python.org>:
So, how is this handled? Until which moment can I expect that the changes in the trunk are merged to Py3k?
Until you hear otherwise :) You can commit py3k-specific changes to the py3k branch, the merges shouldn't lose them. (Of course, mistakes in merging are possible, which is why tests are good :) If I do base the merge on the 2to3 outpt of the trunk version, I'd be careful not to lose changes made in the branch.
Ok, thank you very much!! Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
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.
On 9/27/07, Eric Smith <eric+python-dev@trueblade.com> wrote:
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.
Funny, just a few hours ago Guido mentioned we (meaning I) should write this up in a PEP :) I'll do that in the next few weeks. Obvious to the merger means whatever the merger expects it to mean ;) Yes, checkin comments are good. If an automatic merge fails, and the code isn't straightforward to merge from just looking at the files, looking at the actual changes in both branches is the next step. If the comment says 'backport from py3k' (preferably with which version was backported), that makes it easy to ignore the whole change (but perhaps not later checkins.) After you backport, maintenance should be done in the trunk, not the py3k branch (except of course, for parts that don't apply to the trunk.) I just want to make sure I don't make life more difficult than necessary
for the folks doing the very valuable merge process.
As long as you commit any given thing only once, it's pretty easy to work out. As soon as you find yourself (more than once) committing things to py3k and then realizing it should go to the trunk, you may be making life harder. I appreciate that you're careful about this though, thanks :) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters schrieb:
On 9/27/07, Eric Smith <eric+python-dev@trueblade.com> wrote:
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 think that the 'svnmerge block -r<revision>' command should be used. Or not? Thomas
On 9/28/07, Thomas Heller <theller@ctypes.org> wrote:
Thomas Wouters schrieb:
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 think that the 'svnmerge block -r<revision>' command should be used. Or not?
If you're comfortable with using svnmerge yourself, sure. If you're worried that you might mess up the state of the branch, you can leave it up to us (me.) -- Thomas Wouters <thomas@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
If the differences are few, I prefer that you insert some conditionals that attach different functions based on the version number. That way we can keep a single version of the source that works on all of the pythons. Raymond On Sep 29, 2007, at 8:26 AM, "Thomas Wouters" <thomas@python.org> wrote:
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
On 9/28/07, Thomas Heller <theller@ctypes.org> wrote: Thomas Wouters schrieb: 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 think that the 'svnmerge block -r<revision>' command should be used. Or not?
If you're comfortable with using svnmerge yourself, sure. If you're worried that you might mess up the state of the branch, you can leave it up to us (me.)
-- Thomas Wouters <thomas@python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread! _______________________________________________ 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/python%40rcn.com
participants (5)
-
Eric Smith -
Facundo Batista -
Raymond Hettinger -
Thomas Heller -
Thomas Wouters