Re: A bug in PgNumeric from current CVS head.

"Billy G. Allie" <[email protected]>
Newsgroups gmane.comp.python.db.pypgsql.user
Message-ID <[email protected]>
Adam Buraczewski wrote:
> Hallo everyone,
> 
> I've just seen some new changes in PgNumeric code on CVS and tried to
> play a bit with it :)  Generally it works nice, I hope pyPgSQL 2.3
> would be the point where I start switching my applications to use this
> class more heavily.  However, I think I found some bugs in it.  Look
> at this:

Yes, you definitely found some bugs.  

[...]


> The other, minor problem is with numbers which have a decimal dot but
> don't have any digits after it:

And another bug is found!

[...]

> I think that there is also another problem with the constructor, which
> causes the class to treat minus sign as a digit which counts into
> precision of the number.  I think it shouldn't.  Look at this:

Number three (3) and counting :-)

[...]

> However I am not sure if I correctly understood the meaning of prec
> parameter passed to PgNumeric constructor.  What should happen when
> someone calls it with setting to something else than None?

The prec and scale parameters are there to allow the user to set the precision 
and scale to specific values.  For example, if you wanted a PgNumeric with a 
precision of 10, a scale of 5, and a value of 0.001, you could enter:

    >>> a = PgSQL.PgNumeric('00000.00100')
    >>> a
    <PgNumeric instance - precision: 10 scale: 5 value: 0.00100>
or
    >>> b = PgSQL.PgNumeric('.001', 10, 5)
    >>> b
    <PgNumeric instance - precision: 10 scale: 5 value: 0.00100>


You can also use them to 'cast' an existing PgNumeric to a different precision 
and scale:

    >>> a = PgSQL.PgNumeric(a, 20, 8)
    >>> a
    <PgNumeric instance - precision: 20 scale: 8 value: 0.00100000>

>                                                             Please,
> check my patch before applying.

I did.  I also decided to rework the input routine somewhat.  The routines for 
FloatType and StringType input now share the same code instead of duplicating 
code.  This has the added benefit of of being able to specify an exponent in 
the input string.  For example:

    >>> a = PgSQL.PgNumeric('123.45678e-6')
    >>> a
    <PgNumeric instance - precision: 11 scale: 11 value: 0.00012345678>

> BTW, I wonder why __repr__ operator of all pyPgSQL classes returns
> strings of the form "<something" instead of "<something>" (without
> closing '>' sign)?  Is it made on purpose or is it a mistake? :)

A mistake.  The only case I could find was in PgNumeric.  Did it occur in other place?

Thank you for the bug report and patch.  It is greatly appreciated.


-- 
____       | Billy G. Allie    | Domain....: [email protected]
|  /|      | 7436 Hartwell     | MSN.......: [email protected]
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |
signature.asc (application/pgp-signature, 3 KB)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

Adam Buraczewski wrote:
> Hallo everyone,
> 
> I've just seen some new changes in PgNumeric code on CVS and tried to
> play a bit with it :)  Generally it works nice, I hope pyPgSQL 2.3
> would be the point where I start switching my applications to use this
> class more heavily.  However, I think I found some bugs in it.  Look
> at this:

Yes, you definitely found some bugs.  

[...]


> The other, minor problem is with numbers which have a decimal dot but
> don't have any digits after it:

And another bug is found!

[...]

> I think that there is also another problem with the constructor, which
> causes the class to treat minus sign as a digit which counts into
> precision of the number.  I think it shouldn't.  Look at this:

Number three (3) and counting :-)

[...]

> However I am not sure if I correctly understood the meaning of prec
> parameter passed to PgNumeric constructor.  What should happen when
> someone calls it with setting to something else than None?

The prec and scale parameters are there to allow the user to set the precision 
and scale to specific values.  For example, if you wanted a PgNumeric with a 
precision of 10, a scale of 5, and a value of 0.001, you could enter:

    >>> a = PgSQL.PgNumeric('00000.00100')
    >>> a
    <PgNumeric instance - precision: 10 scale: 5 value: 0.00100>
or
    >>> b = PgSQL.PgNumeric('.001', 10, 5)
    >>> b
    <PgNumeric instance - precision: 10 scale: 5 value: 0.00100>


You can also use them to 'cast' an existing PgNumeric to a different precision 
and scale:

    >>> a = PgSQL.PgNumeric(a, 20, 8)
    >>> a
    <PgNumeric instance - precision: 20 scale: 8 value: 0.00100000>

>                                                             Please,
> check my patch before applying.

I did.  I also decided to rework the input routine somewhat.  The routines for 
FloatType and StringType input now share the same code instead of duplicating 
code.  This has the added benefit of of being able to specify an exponent in 
the input string.  For example:

    >>> a = PgSQL.PgNumeric('123.45678e-6')
    >>> a
    <PgNumeric instance - precision: 11 scale: 11 value: 0.00012345678>

> BTW, I wonder why __repr__ operator of all pyPgSQL classes returns
> strings of the form "<something" instead of "<something>" (without
> closing '>' sign)?  Is it made on purpose or is it a mistake? :)

A mistake.  The only case I could find was in PgNumeric.  Did it occur in other place?

Thank you for the bug report and patch.  It is greatly appreciated.


- -- 
____       | Billy G. Allie    | Domain....: [email protected]
|  /|      | 7436 Hartwell     | MSN.......: [email protected]
|-/-|----- | Dearborn, MI 48126|
|/  |LLIE  | (313) 582-1540    |


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (UnixWare)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE97agFnmIkMXoVVdURApqHAKC7y8KI50UEe2UEOoA1knIJJ7bfjwCeJTMH
zbjNDiDbVFmxGkyrU10dR+I=
=5HFx
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.