Re: deprecation of pkgutil.extend_path()?

Brett Cannon <[email protected]>
Newsgroups gmane.comp.python.import
Message-ID <CAP1=2W7qKaEd7vTmeZVSUj6bifeOwXY8hi5vXeHvuxhVzffbJA@mail.gmail.com>
On Thu, Jul 18, 2013 at 6:28 PM, Eric V. Smith <[email protected]> wrote:

> On 7/18/2013 6:20 PM, Eric Snow wrote:
> > Was there any discussion, relative to PEP 420, about deprecating
> > pkgutil.extend_path()?  The PEP talks about transitioning away from the
> > function, but does not talk about deprecation.
>
> I don't recall any such discussion. It just never came up.
>

The idea came up, but no one laid down a schedule since namespace packages
are so new.


>
> > I ask because the PEP I just posted to this list fills the role played
> > by the `.pkg` files that extend_path() uses.  Since the two are tightly
> > coupled, it doesn't make sense to deprecate one without doing so for the
> > other.
> >
> > Is there any reason not to put extend_path() on a (conservative)
> > deprecation schedule?  Considering that it's related and that I'm
> > proposing deprecation of `.pth` files, I can simply include such a
> > schedule as part of my PEP.
>
> I haven't read the PEP yet, so I'll have to wait to comment. I'm not
> opposed to removing it, though.
>

I think you can add a PendingDeprecationWarning for it (probably should
double-check nothing else in pkgutil no longer makes sense as well).

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.