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 brett.cannon
Recipients brett.cannon, eric.snow, pitrou, r.david.murray
Date 2012-04-17.16:07:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP1=2W64P2en0eicY3E5rfcfQtgVsFBi8N97=zMu7--Eerfb3Q@mail.gmail.com>
In-reply-to <1334659856.3338.12.camel@localhost.localdomain>
Content
On Tue, Apr 17, 2012 at 06:51, Antoine Pitrou <report@bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> > Well, I want backwards-compatibility *now*, not forever.
>
> I don't think changing a function signature in an incompatible way is
> generally acceptable.

I don't think it is either.

> You might make one of the arguments optional,
> though (but keeping the current semantics when the argument *is*
> passed). If it's not possible, you can add another function with the
> intended behaviour.
>

Right, which is why I'm thinking that I could make the module name argument
optional for load_module() to avoid repeating yourself since that
information is passed to the constructor.

>
> The importlib bootstrapping has already had some (unavoidable)
> disruptive consequences. Let's keep them to a minimum. People *rely* on
> our APIs, even the less popular ones.

Which is unfortunate when the API is bad. Anyway, the deprecation can be a
long one, but I don't want people having to look in two places for
import-related stuff like urllib/urllib2 caused for URLs.
History
Date User Action Args
2012-04-17 16:07:15brett.cannonsetrecipients: + brett.cannon, pitrou, r.david.murray, eric.snow
2012-04-17 16:07:14brett.cannonlinkissue14551 messages
2012-04-17 16:07:14brett.cannoncreate