Benjamin Peterson wrote:
2009/4/24 Eric Smith :
My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in
3.2.
Having heard no dissent, I'd like to go ahead and deprecate this API. What
are the mechanics of deprecating this? Just documentation, or is there
something I should do in
2009/4/24 Eric Smith :
>> My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in
>> 3.2.
>
> Having heard no dissent, I'd like to go ahead and deprecate this API. What
> are the mechanics of deprecating this? Just documentation, or is there
> something I should do in the code to gen
Eric Smith wrote:
Assuming that Mark's and my changes in the py3k-short-float-repr branch
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its
functionality is largely being replaced by PyOS_double_to_string, which
we're introducing on our branch.
We've checked the changes in
Nick Coghlan wrote:
Eric Smith wrote:
And as a reminder, the py3k-short-float-repr changes are on Rietveld at
http://codereview.appspot.com/33084/show. So far, no comments.
Looks like you were able to delete some fairly respectable chunks of
redundant code!
Wait until you see how much nasty
Eric Smith wrote:
> And as a reminder, the py3k-short-float-repr changes are on Rietveld at
> http://codereview.appspot.com/33084/show. So far, no comments.
I skipped over the actual number crunching parts (the test suite will do
a better job than I will of telling you whether or not you have thos
Assuming that Mark's and my changes in the py3k-short-float-repr branch
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its
functionality is largely being replaced by PyOS_double_to_string, which
we're introducing on our branch.
PyOS_ascii_formatd was introduced to fix the is
