[issue1742669] "%d" format handling for long values

[Pádraig Brady]

Pádraig Brady <[EMAIL PROTECTED]> added the comment:

A couple of comments.

1. This bug supersedes issue 1153226
That has good info, including the suggestion that one should
be using the %.f format rather than %d in this case anyway

2. The patch here was actually applied in r61041

--
nosy: +pixelbeat

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Facundo Batista]

Facundo Batista added the comment:

Applied in r61040. Thanks you all!

--
resolution:  -> accepted
status: open -> closed

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Facundo Batista]

Facundo Batista added the comment:

Paul, %d will accept large floats, I need to review Gabriel's patch;
your proposition will break too much code.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc added the comment:

I am of the opposite side:
%d should accept floats and anything that can be converted to an integer.
It is for printing objects with a decimal format.
(likewise %s is for printing objects that can be converted to a string)

--
nosy: +amaury.forgeotdarc

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[paul rubin]

paul rubin added the comment:

I would prefer that %d signal an error 100% of the time if you give it a
float.  It should not accept 42.0.  It is for printing integers.

--
nosy: +phr

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Gabriel Genellina]

Gabriel Genellina added the comment:

An updated patch, along the lines given by Travis Oliphant.

Added file: http://bugs.python.org/file9458/floatfmt.diff

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Facundo Batista]

Facundo Batista added the comment:

Closed issue 1924 as duplicate of this one, but I'm copying here the
text from David, as it's very explanative:

"""
I ran across this bug in some legacy production code when numbers got high:

>>> '%i' % 2e9
'20'
>>> '%i' % 3e9
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: int argument required

It looks like the float is being automatically converted to an int, but
floats > sys.maxint cause an error.  However,

>>> int(3e9)
30L

So the implicit float-to-int conversion is imperfect; large floats are
not being converted to long ints.

Same error in Python 2.3 through 2.6a0 (as of 2007-12-28).

In Python 2.1.3 & 2.2.3 the error is "OverflowError: float too large to
convert".  The same error is triggered by int(3e9) though.

While it's arguably not-quite-sane to have code that triggers this
error, the inconsistency is what concerns me.
"""

--
nosy: +goodger

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Gabriel Genellina]

Gabriel Genellina added the comment:

Yes, I can reformulate it. In fact my original version was quite 
different, but the resulting diff was hard to understand so I rewrote 
it trying to keep as much as the original code as possible.
I'll submit a new patch next weekend.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Facundo Batista]

Facundo Batista added the comment:

I'm positive that this shouldn't happen. There should NOT be any
difference between longs and ints in nowadays Python, so you never
should say to an user to call that long() before the %d.

And, you have some strange behaviours... for example:

>>> "%d" % 9e8
'9'
>>> "%d" % 9e9
Traceback (most recent call last):
  File "", line 1, in 
TypeError: int argument required

Why the first is ok and in the second you should have called it through
long()?

Gabriel, could you please take a look to the recommendations that Travis
is doing? Maybe the patch could be simpler... In any case, please
confirm if yes or no, :)

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1742669] "%d" format handling for long values

[Travis Oliphant]

Travis Oliphant added the comment:

I have two issues with this patch:

1) I'm not sure it's that bad to need to use '%d' % long(obj) to ensure
conversion to a long integer.

2) If this kind of auto-conversion is deemed useful, then the patch
itself is rather complicated.   I would re-factor so that the same code
is not repeated once in the PyNumber_Check and again in the original
PyLong_Check and else clauses.  Simply check for PyNumber.  Then, if not
already an int or a long, convert to int first and then long if that
creates an error.  Then, excecute the two segments of code for int and
long objects.

--
nosy: +teoliphant

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com