There's a minor inconsistency between Decimal and float formatting for the `%` format type when handling infinities and nans:

>>> from decimal import Decimal
>>> format(float('inf'), '.2%')  # includes trailing '%'
'inf%'
>>> format(Decimal('inf'), '.2%')  # no trailing '%'
'Infinity'

I think the Decimal result should have a '%' on it.

I agree that Decimal is wrong here. PEP 3101 says the result should include the trailing '%'.

I guess it's the right thing to do and here's a patch. Could one of you double check the decimal.py part?

The decimal.py part LGTM.  (The rest looks good, too, but I haven't tested it.)  This seems like one of those bugs that probably isn't worth backporting to 3.4, but given the projected longevity of 2.7 it might be worth applying there.

Thanks.  I agree about 2.7 -- including 3.4 would perhaps make
external libmpdec management easier for Debian and Arch.

I'm not suggesting that we should always consider the distributors,
but this particular issue seems so minor.

New changeset 5c585929658a by Stefan Krah in branch '3.4':
Issue #22090: Fix '%' formatting for infinities and NaNs.
http://hg.python.org/cpython/rev/5c585929658a

New changeset 37ebb0d44808 by Stefan Krah in branch '2.7':
Issue 22090: Fix '%' formatting for infinities and NaNs.
http://hg.python.org/cpython/rev/37ebb0d44808

Looks like there is a bug of some sort, eg:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.4/builds/466

I think only the builders --with-system-libmpdec fail.  That's inevitable, since they still use libmpdec-2.4.0.

Starting from 7fbb912c0789 they should fail building _decimal entirely until I upgrade the system libmpdec on the builders.

It seems _decimal is imported even if _decimal.so is not built.
I've opened #22280 for that.

Regarding this patch, everything looks fine to me.

As long as you have a plan to get the buildbots fixed in a timely fashion.

(To be clear, I'm talking about the stable buildbots :)

I'm not sure that I understand. IMHO this issue does not break any buildbots.
The current situation is that it exposes an unrelated import issue (#22280).

I can camouflage that issue by upgrading the FreeBSD and the Fedora bot to
libmpdec-2.4.1 (once it's out), but I'd rather see the import issue fixed
first.

Well, we have a goal of keeping the stable buildbots green.  If something turns one or more red, it should either be fixed promptly, or the changeset that turned it red backed out until a fix is ready.

The reason for keeping them green is so we know right away when a changeset is bad.  If some are red, we don't get alerted to new breakage.

The revisions that cause the bot to go red (6c468df214dc and 227ce85bdbe0) are
quite recent, so I suggest we address the failure in #22285.

I'm not going to argue this any further, but "recent" is exactly the point...if all of the bots had turned red you'd understand that it needed to be fixed *immediately* or the triggering change (regardless of what the actual bug was) backed out.  Since it isn't all the bots it isn't that critical, but eventually we want to make it critical (ie: someday it will be a requirement that *all* stable bots pass before a change gets *committed*...but that day is still a longer way off than I'd like, since I at least don't have much time for working on the workflow stuff).

> I'm not going to argue this any further, but "recent" is exactly the point...if all of the bots had turned red you'd understand that it needed to be fixed *immediately* or the triggering change (regardless of what the actual bug was) backed out.  Since it isn't all the bots it isn't that critical, but eventually we want to make it critical (ie: someday it will be a requirement that *all* stable bots pass before a change gets *committed*...but that day is still a longer way off than I'd like, since I at least don't have much time for working on the workflow stuff).

How is this supposed to work though?  In this case 6c468df214dc and 227ce85bdbe0
need to be backed out, since they apparently also broke the OpenIndiana bot long
ago (why wasn't that discovered?).

However, I don't feel that it is my place to back them out, since I did not
commit them and might step on other people's toes.

I don't think that the burden of having green buildbots should be on the
person who commits something that *exposes* existing issues (unless, as
you say, *all* buildbots turn red).

Yeah, right now that's fine.  We'll work out the more strict process if/when we start actually enforcing it :)