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
Barry A. Warsaw added the comment:
Fix:
'%.32x' % uuid4().int
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
Python-bugs-list
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
--
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
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
Changes by Josh Rosenberg shadowranger+pyt...@gmail.com:
--
nosy: +josh.rosenberg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
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
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
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
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
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
STINNER Victor added the comment:
Typo in the C code: depracation :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
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
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
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
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
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
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
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
___
Antoine Pitrou added the comment:
(also, there are typos: shuld, psuedo)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
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
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
___
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
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.
--
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
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
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
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
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
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19995
___
___
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
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
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.
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
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
___
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
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,
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()
38 matches
Mail list logo
