Message158554
| 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. |
|