[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Barry A. Warsaw added the comment: Found my first 3.5 breakage which I think is due to this. from uuid import uuid4 '%.32x' % uuid4() -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Barry A. Warsaw added the comment: Fix: '%.32x' % uuid4().int -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Roundup Robot added the comment: New changeset e266525c9294 by Ethan Furman in branch 'default': Issue19995: more informative error message; spelling corrections; use operator.mod instead of __mod__ http://hg.python.org/cpython/rev/e266525c9294 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: Final status: 3.4 - DeprecationWarning 3.5 - TypeError -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Roundup Robot added the comment: New changeset 9120196b3114 by Ethan Furman in branch 'default': Issue19995: passing a non-int to %o, %c, %x, or %X now raises an exception http://hg.python.org/cpython/rev/9120196b3114 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Changes by Josh Rosenberg shadowranger+pyt...@gmail.com: -- nosy: +josh.rosenberg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Stefan Krah added the comment: It looks like there's typo: Psuedo = Pseudo. (Unless the first one is an alternate spelling I'm not aware of.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: No, apparently I am incapable of spelling pseudo correctly. I'll fix that along with the better error message: %x format: an integer is required, not float (variable, obviously ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Roundup Robot added the comment: New changeset 775fb736b4b8 by Serhiy Storchaka in branch 'default': Catch deprecation warnings emitted when non-integers are formatted with %c, %o http://hg.python.org/cpython/rev/775fb736b4b8 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: Depracation warning is in place for 3.4. When 3.5 is tagged I'll switch it an error. -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
STINNER Victor added the comment: Typo in the C code: depracation :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Roundup Robot added the comment: New changeset cc8b21988efb by Ethan Furman in branch 'default': Issue19995: fixed typo; switched from test.support.check_warnings to assertWarns http://hg.python.org/cpython/rev/cc8b21988efb -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Roundup Robot added the comment: New changeset 22e55bd5583c by Ethan Furman in branch 'default': Issue19995: issue deprecation warning for non-integer values to %c, %o, %x, %X http://hg.python.org/cpython/rev/22e55bd5583c -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: For anyone paying really close attention, I've already switched the assertEquals to assertEqual. ;) -- Added file: http://bugs.python.org/file33414/issue19995.stoneleaf.04.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: Could somebody explain this? === ethan@media:~/source/python/issue19995_depr$ ./python -W error Python 3.4.0b1 (default:2f81f0e331f6+, Jan 9 2014, 20:30:18) [GCC 4.7.3] on linux Type help, copyright, credits or license for more information. '%x' % 3.14 oxX no __index__ depracation is fatal oxX no __index__ depracation is fatal Traceback (most recent call last): File stdin, line 1, in module DeprecationWarning: automatic int conversions have been deprecated === ethan@media:~/source/python/issue19995_depr$ ./python -W message Invalid -W option ignored: invalid action: 'message' Python 3.4.0b1 (default:2f81f0e331f6+, Jan 9 2014, 20:30:18) [GCC 4.7.3] on linux Type help, copyright, credits or license for more information. '%x' % 3.14 oxX no __index__ depracation not fatal, attempting __int__ conversion conversion with __int__ successful '3' === ethan@media:~/source/python/issue19995_depr$ ./python -W once Python 3.4.0b1 (default:2f81f0e331f6+, Jan 9 2014, 20:30:18) [GCC 4.7.3] on linux Type help, copyright, credits or license for more information. '%x' % 3.14 oxX no __index__ sys:1: DeprecationWarning: automatic int conversions have been deprecated depracation not fatal, attempting __int__ conversion conversion with __int__ successful '3' === As you can see, with the -W error option it seems to go through the routine twice; does that mean the the '1' in 'line 1' is being specified as a float? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Roundup Robot added the comment: New changeset 2f81f0e331f6 by Ethan Furman in branch 'default': Issue19995: %o, %x, %X now only accept ints http://hg.python.org/cpython/rev/2f81f0e331f6 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: I was travelling yesterday and wasn't sure about the time stamp. Looks like I missed the 12-hour cutoff. Let me know if I should backout the commit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Antoine Pitrou added the comment: Ethan, I thought we were going the deprecation route? This *will* break code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Antoine Pitrou added the comment: (also, there are typos: shuld, psuedo) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Larry Hastings added the comment: Antoine: I made the call to bite the bullet and fix it. If that's a terrible idea we can change it before RC1. But from my (admittedly dim) understanding of the issue, we're going to have to fix this sooner or later, and sooner is probably better. If by permitting this I've made a terrible mistake, could you do me a favor and summarize the issue and the alternatives so I can understand it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Larry Hastings added the comment: And, yes, Ethan's checkin missed the cutoff for beta 2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: I think the code-breakage issue is that although this is a bug now, it did not use to be a bug. (Or maybe it was always a bug, but nobody noticed -- I don't know when hex() and oct() were introduced.) Basically, having %o and %x work with floats was the intended behavior, as there were tests to make sure it worked. But hex() and oct() were designed to only work with integer types, resulting in two ways to get an octal or hexadecimal string, one of which worked with non-ints, and one which didn't. tarfile.py, for example, was using %o to convert a stat member (a timestamp?) from int/float to octal. It is agreed that working with non-ints is no longer the intended behavior, but there is undoubtedly code that uses it -- especially in cases where the return value could be either an int or a float. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
R. David Murray added the comment: Given that even the stdlib used it, there is no question in my mind that a deprecation period is required. We don't just arbitrarily break peoples code on purpose, we give them at least a release in which to fix it first. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Antoine Pitrou added the comment: Keep in mind that with new-style division, it's easy to get a float even if all your inputs are ints. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: I'll switch it to a deprecation warning instead sometime this week. The changes to datamodel.rst and tarfile.py should stay, I think. test_format and test_unicode will both verify current* behavior and check for the deprecation warning, and unicodeobject.c will generate the warning but keep current behavior. Once 3.5 is tagged I'll put the updates to these three files there. * By 'current' I mean accepting non-ints. -- versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Terry J. Reedy added the comment:
Merely from reading the docs, including the hex() and {}.format sections, I
consider the current
'%x' % 1.5 == '1'
a bug in that I would expect either a Type or Value Error
or a hex fraction(!) ('1,8') matching the core of the output of float.hex(1.5).
But given the history, I agree that a deprecation notice is needed first.
In 3.3 section 6.1.3.1. Format Specification Mini-Language, integer and float
conversions are in separate tables, so no confusion is possible. In 3.3 section
4.7.2. printf-style String Formatting there is just one table with all
conversion chars. I think the table would be clearer if it were somehow split
into three sections: perhaps 3 otherwise blank rows containing 'integer',
'float', and 'other' in the Conversion column. (I don't know if this works for
.rst tables.)
I think I would change the table for 3.4 with a note 8 that 'o', 'x', and 'X'
currently accept floats by calling int() on the value, but that this implicit
behavior is deprecated, so one should be explicit. The DeprecationWarning
should also give the same remedy.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Larry Hastings added the comment: I'm willing to risk it in 3.4. Can you check it in in the next twelve hours? (Sorry for the short notice, it slipped my mind until just now.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: Better doc enhancement thanks to R. David Murray (thanks!). -- Added file: http://bugs.python.org/file33289/issue19995.stoneleaf.03.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Eric V. Smith added the comment: While I think this is an improvement, I don't think we can make this change in behavior at this stage in 3.4. Won't it have to go in 3.5? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: I can see why we wouldn't want to make this change in a point release, but this is a feature release we're talking about and this seems like buggy behavior: -- hex(3.14) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'float' object cannot be interpreted as an integer -- '%x' % 3.14 '3' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Eric V. Smith added the comment: I agree the behavior is bad and should be fixed. But it's a new feature that will break existing code, and 3.4 is in beta, and therefore feature freeze. Unfortunately, I think this has to go into 3.5, unless you can get Larry to grant you an exception. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
R. David Murray added the comment: We don't usually *break* existing working code even if the output is wrong. If you want to make '%x' % 3.14, etc, raise an error, I think you we should go through a deprecation period first. The deprecation messages should, of course, be added now. In other words, I would probably have voted against commit even if we weren't in beta yet. It's a bit borderline, since the output is *wrong*, but given that we *are* in beta I think we'd better go the deprecation route. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: I can live with the deprecation route. I'll create a patch today or tomorrow for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Larry Hastings added the comment: I wouldn't call this a new feature--it's definitely a bug fix. So the feature freeze rule does not automatically apply. I definitely wouldn't permit this once we reach release candidates, but we aren't there yet. I get the impression that it will break code, and it does seem kind of late. So I'm not saying yes or no yet. Let me think about it some more. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: Ran full test suite; some errors came up in test_format from the following test lines: testformat(%#x, 1.0, 0x1) testformat(%x, float(big), 123456___, 6) testformat(%o, float(big), 123456__, 6) testformat(%x, float(0x42), 42) testformat(%o, float(0o42), 42) Removed as float() is not supposed to be valid input. Also fixed two memory leaks in unicodeobject from my changes, and a float-oct bug in tarfile. -- Added file: http://bugs.python.org/file33286/issue19995.stoneleaf.02.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception
Ethan Furman added the comment: Enhancement portion split off into issue20092. Attached patch includes doc change, tests, and code changes. If I'm overstepping my bounds, I'm sure somebody will slap me with a fish. ;) -- keywords: +patch stage: test needed - patch review title: hex() and %x, oct() and %o do not behave the same - %c, %o, %x, %X accept non-integer values instead of raising an exception type: enhancement - behavior versions: +Python 3.4 -Python 3.5 Added file: http://bugs.python.org/file33284/issue19995.stoneleaf.01.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
