In November there was an interesting discussion on comp.lang.python about the meaning of __str__ and __repr__. One tidbit that came out of this discussion was that __str__ for longs should drop the trailing 'L'. Was there a decision on this? I'd really like this to happen. We do alot of work with RDBMS systems and long integers seem to come up alot with these systems (as do other fix-decimal number, but that's another topic ;). For example, our latest Sybase and Oracle support in Zope returns long integers for RDBMS types like NUMBER(10,0). The trailing 'L' in the string representation is causeing us some headaches. This seems also to be an issue when using the current standard ODBC interface with Oracle, as indicated in a DB-SIG post today. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
[Jim F]
In November there was an interesting discussion on comp.lang.python about the meaning of __str__ and __repr__. One tidbit that came out of this discussion was that __str__ for longs should drop the trailing 'L'. Was there a decision on this? I'd really like this to happen.
Yes, I'd like it to happen. I'd also like repr() of a float to return the full precision (using the "%.17g" sprintf format). I haven't done it for lack of time -- feel free to send a patch (don't forget the disclaimer from http://www.python.org/1.5/bugrelease.html). We haven't decided yet what to do with the greater topic of that discussion (or was it a different one?) -- whether the values printed by typing a bare expression in interactive mode should use str(), repr(), or str-special-casing-the-snot-out-of-strings(). --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
[Jim F]
In November there was an interesting discussion on comp.lang.python about the meaning of __str__ and __repr__. One tidbit that came out of this discussion was that __str__ for longs should drop the trailing 'L'. Was there a decision on this? I'd really like this to happen.
Yes, I'd like it to happen. I'd also like repr() of a float to return the full precision (using the "%.17g" sprintf format).
While we're at it: how about adding a PyLong_AsString() API to the C interface ? I currently use PyObject_Str() in mxODBC and then slice off the 'L' -- not very elegant. A PyLong_AsString() API would much better suit the task. Merry Christmas, -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 7 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Fri, 24 Dec 1999, M.-A. Lemburg wrote:
Guido van Rossum wrote:
[Jim F]
In November there was an interesting discussion on comp.lang.python about the meaning of __str__ and __repr__. One tidbit that came out of this discussion was that __str__ for longs should drop the trailing 'L'. Was there a decision on this? I'd really like this to happen.
Yes, I'd like it to happen. I'd also like repr() of a float to return the full precision (using the "%.17g" sprintf format).
While we're at it: how about adding a PyLong_AsString() API to the C interface ? I currently use PyObject_Str() in mxODBC and then slice off the 'L' -- not very elegant. A PyLong_AsString() API would much better suit the task.
Fred just checked in a change yesterday. PyObject_Str() on a Long no longer includes the 'L'. You're going to need to update your code :-) [ I've got some here and there to fix, too, with the idiom: if type(v) is type(1L): return str(v)[:-1] ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein wrote:
On Fri, 24 Dec 1999, M.-A. Lemburg wrote:
While we're at it: how about adding a PyLong_AsString() API to the C interface ? I currently use PyObject_Str() in mxODBC and then slice off the 'L' -- not very elegant. A PyLong_AsString() API would much better suit the task.
Fred just checked in a change yesterday. PyObject_Str() on a Long no longer includes the 'L'.
Ah, ok... scanning the patches: they don't provide an externed C interface... I would like to have such a beast if possible (basically, the new long_format() as PyLong_AsString()).
You're going to need to update your code :-) [ I've got some here and there to fix, too, with the idiom: if type(v) is type(1L): return str(v)[:-1] ]
Your above example will effectively divide the long value by 10 which will probably break things in very subtle ways... hmm, this change ought to be made *very* visible to people upgrading to 1.6, IMHO. I'll fix mxODBC to only truncate the string value iff the 'L' is present. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 5 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Sun, 26 Dec 1999, M.-A. Lemburg wrote:
Greg Stein wrote:
On Fri, 24 Dec 1999, M.-A. Lemburg wrote:
While we're at it: how about adding a PyLong_AsString() API to the C interface ? I currently use PyObject_Str() in mxODBC and then slice off the 'L' -- not very elegant. A PyLong_AsString() API would much better suit the task.
Fred just checked in a change yesterday. PyObject_Str() on a Long no longer includes the 'L'.
Ah, ok... scanning the patches: they don't provide an externed C interface... I would like to have such a beast if possible (basically, the new long_format() as PyLong_AsString()).
What's wrong with PyObject_Str()? I don't see a need for Yet Another Entry Point.
You're going to need to update your code :-) [ I've got some here and there to fix, too, with the idiom: if type(v) is type(1L): return str(v)[:-1] ]
Your above example will effectively divide the long value by 10 which will probably break things in very subtle ways... hmm, this
Yah :-( Not a lot of fun, but I think for the best.
change ought to be made *very* visible to people upgrading to 1.6, IMHO.
Yes. Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein wrote:
On Sun, 26 Dec 1999, M.-A. Lemburg wrote:
Greg Stein wrote:
On Fri, 24 Dec 1999, M.-A. Lemburg wrote:
While we're at it: how about adding a PyLong_AsString() API to the C interface ? I currently use PyObject_Str() in mxODBC and then slice off the 'L' -- not very elegant. A PyLong_AsString() API would much better suit the task.
Fred just checked in a change yesterday. PyObject_Str() on a Long no longer includes the 'L'.
Ah, ok... scanning the patches: they don't provide an externed C interface... I would like to have such a beast if possible (basically, the new long_format() as PyLong_AsString()).
What's wrong with PyObject_Str()? I don't see a need for Yet Another Entry Point.
What's wrong with a rich C API :-) ? The long_format function would be very useful for programs interacting with other software at C level. Making it external would give the programmer the ability to pass long string representations in any base to other programs, which is very useful for e.g. database interaction or crypto software. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 4 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Jim Fulton writes:
In November there was an interesting discussion on comp.lang.python about the meaning of __str__ and __repr__. One tidbit that came out of this discussion was that __str__ for longs should drop the trailing 'L'. Was there a decision on this? I'd really like this to happen.
I liked that result as well, and thought about it just the other day. Luckily, you sent a note this morning and made me think about again. I'll have something checked into CVS shortly. ;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
participants (5)
-
Fred L. Drake, Jr. -
Greg Stein -
Guido van Rossum -
Jim Fulton -
M.-A. Lemburg