classification
Title: Deprecate PyOS_ascii_formatd
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: eric.smith Nosy List: eric.smith, mark.dickinson
Priority: release blocker Keywords:

Created on 2009-04-25 07:44 by eric.smith, last changed 2009-04-27 11:52 by eric.smith. This issue is now closed.

Messages (4)
msg86446 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-04-25 07:44
PyOS_ascii_formatd is no longer needed, now that we have
PyOS_double_to_string. PyOS_ascii_formatd has a horrible interface,
requiring a format string to be composed and then parsed. The format
string is a very limited printf-like format string.

In 2.7 and 3.1 I'm going to deprecate this function. As a temporary
measure I'm going to create a similar function _PyOS_ascii_formatd (with
a leading underscore) that does not raise a DeprecationWarning and that
takes discrete parameters.

In 2.8 (if it exists) and 3.2 I'll remove PyOS_ascii_formatd.
msg86551 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-04-25 21:04
It makes most sense to name the new 2.7 replacement function to be
_PyOS_double_to_string (with a leading underscore). It will be the same
as PyOS_double_to_string, except that instead of allocating a buffer and
returning it, you will supply it a buffer and a length. That will make
its ultimate replacement easy, if I decide to replace it. And having it
take a buffer and a length means that I don't need to do major surgery
in all of the places that it's called.

In 3.1, there will be no replacement function. All 3.1 code has already
been modified to call PyOS_double_to_string directly.

Since PyOS_ascii_formatd won't be called anywhere in 2.7 or 3.1, I'm
planning on testing its functionality and the fact that it's deprecated
using ctypes.
msg86558 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-04-25 21:41
Committed in trunk as r71938. I'll use a slightly different strategy in
py3k.
msg86657 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-04-27 11:52
Checked in for trunk (r71938) and py3k (r71989).
History
Date User Action Args
2010-02-22 15:00:28eric.smithlinkissue5988 superseder
2009-04-27 11:52:49eric.smithsetstatus: open -> closed
resolution: accepted
messages: + msg86657
2009-04-25 21:41:11eric.smithsetmessages: + msg86558
2009-04-25 21:04:15eric.smithsetmessages: + msg86551
2009-04-25 07:44:54eric.smithcreate