> No, but it is still a one-line function that those who need it can
> easily implement.

It's so easy that the patch isn't a one-liner and it seems to still have
bugs wrt. intended behaviour.

>   I am on the fence here because we already have
> date.isocalendar() function, so it is natural to desire its inverse,
> but still at least on this side of the pond an Easter(year) date
> constructor would see more use than that.

This isn't an either/or situation. We can have both from_iso_week() and
Easter() if both are useful.
And I don't get this "side of the pond" argument. Python is not meant
only for the American public, that's why all strings are now unicode.