<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 6:28 PM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 7/18/2013 6:20 PM, Eric Snow wrote:<br>
> Was there any discussion, relative to PEP 420, about deprecating<br>
> pkgutil.extend_path()?  The PEP talks about transitioning away from the<br>
> function, but does not talk about deprecation.<br>
<br>
</div>I don't recall any such discussion. It just never came up.<br></blockquote><div><br></div><div>The idea came up, but no one laid down a schedule since namespace packages are so new.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="im"><br>
> I ask because the PEP I just posted to this list fills the role played<br>
> by the `.pkg` files that extend_path() uses.  Since the two are tightly<br>
> coupled, it doesn't make sense to deprecate one without doing so for the<br>
> other.<br>
><br>
> Is there any reason not to put extend_path() on a (conservative)<br>
> deprecation schedule?  Considering that it's related and that I'm<br>
> proposing deprecation of `.pth` files, I can simply include such a<br>
> schedule as part of my PEP.<br>
<br>
</div>I haven't read the PEP yet, so I'll have to wait to comment. I'm not<br>
opposed to removing it, though.<br></blockquote><div><br></div><div>I think you can add a PendingDeprecationWarning for it (probably should double-check nothing else in pkgutil no longer makes sense as well). </div></div>

</div></div>