This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients amaury.forgeotdarc, barry, eli.bendersky, eric.snow, ethan.furman, ncoghlan, pitrou
Date 2013-06-19.14:32:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1371652339.96.0.43782380471.issue18264@psf.upfronthosting.co.za>
In-reply-to
Content
While I agree with forcing int subclasses to true integers in the JSON module, that may not be enough - the problem will affect third party serialisers as well. Whiel the debugging gains won't be as high, we may need to override __str__() in enum.IntEnum to give the "raw" form (leaving the debugging form solely for repr).

As for the float behaviour, the JSON serialiser is almost certainly playing games to avoid the truncation that used to occur in float.__str__ (I don't recall if we actually got rid of that, or if it's just a lot harder to trigger these days - it definitely changed when float.__repr__ was updated to prefer human friendly representations that produce the same floating point number). I'm less concerned about that, since we don't plan to swap out any standard library floats for enums. We may still want to mention the potential compatibility issue somewhere in the docs, though.

Backwards compatibility is such fun, isn't it? :)
History
Date User Action Args
2013-06-19 14:32:20ncoghlansetrecipients: + ncoghlan, barry, amaury.forgeotdarc, pitrou, eli.bendersky, ethan.furman, eric.snow
2013-06-19 14:32:19ncoghlansetmessageid: <1371652339.96.0.43782380471.issue18264@psf.upfronthosting.co.za>
2013-06-19 14:32:19ncoghlanlinkissue18264 messages
2013-06-19 14:32:19ncoghlancreate