Mailing List Archive: str(1L) -> '1' ?

str(1L) -> '1' ?

Dec 23, 1999, 7:41 AM

Post #1 of 8 (2988 views)

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.

Re: str(1L) -> '1' ? [ In reply to ]

guido at CNRI

Dec 23, 1999, 7:46 AM

Post #2 of 8 (2950 views)

Permalink

[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/)

Re: str(1L) -> '1' ? [ In reply to ]

fdrake at acm

Dec 23, 1999, 8:27 AM

Post #3 of 8 (2949 views)

Permalink

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

Re: str(1L) -> '1' ? [ In reply to ]

mal at lemburg

Dec 24, 1999, 4:03 AM

Post #4 of 8 (2951 views)

Permalink

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/

Re: str(1L) -> '1' ? [ In reply to ]

gstein at lyra

Dec 24, 1999, 1:13 PM

Post #5 of 8 (2954 views)

Permalink

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/

Re: str(1L) -> '1' ? [ In reply to ]

mal at lemburg

Dec 26, 1999, 3:29 PM

Post #6 of 8 (2950 views)

Permalink

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/

Re: str(1L) -> '1' ? [ In reply to ]

gstein at lyra

Dec 27, 1999, 4:31 AM

Post #7 of 8 (2941 views)

Permalink

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/

Re: str(1L) -> '1' ? [ In reply to ]

mal at lemburg

Dec 27, 1999, 5:51 AM

Post #8 of 8 (2956 views)

Permalink

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/