[Python-bugs-list] [Bug #127273] Documentation of 'long' function is wrong

noreply@sourceforge.net noreply@sourceforge.net
Wed, 03 Jan 2001 21:09:59 -0800


Bug #127273, was updated on 2001-Jan-02 03:13
Here is a current snapshot of the bug.

Project: Python
Category: Documentation
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: jribbens
Assigned to : fdrake
Summary: Documentation of 'long' function is wrong

Details: It appears that in Python 2.0, the built-in function 'long' has
been improved to allow a radix parameter. This is not listed in the
documentation (Library Reference). It is quite important that it is,
because with the string.atol function being deprecated I don't think there
is any other way to parse a hex string.


Follow-Ups:

Date: 2001-Jan-03 21:09
By: fdrake

Comment:
Fixed in Doc/lib/libfuncs.tex revision 1.73.

-------------------------------------------------------

Date: 2001-Jan-02 11:38
By: fdrake

Comment:
Fixed in my working sources, but checkin is held up by a stale CVS
read-lock:

http://sourceforge.net/support/?func=detailsupport&support_id=110927&group_id=1

I'll close this bug when I can check in the changes.
-------------------------------------------------------

Date: 2001-Jan-02 08:27
By: tim_one

Comment:
Fred, I see that the current CVS version already documents the radix
argument to long().  But both it and the docs for int() say

"""
   If the argument is a string, it must contain a
   possibly signed decimal number ...
"""

That's inaccurate now (since the radix argument was added -- it was the
truth before the radix argument was allowed).

-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=127273&group_id=5470