<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 29, 2013 at 5:43 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Just a general comment: spec and module mismatches have to be considered *normal*, and the module has to take precedence. Otherwise you risk breaking too much code.</p>


<p dir="ltr">The spec is *not* authoritative in general. The only exception is that when __name__ ends with "__main__", pickle should be updated to look at the name on the spec instead.</p>
<p dir="ltr">Even the attribute setting after create_module should respect custom settings provided by the loader.</p></blockquote><div><br></div><div>I agree with this. Modules that change values during their importation/execution will be setting __name__, __package__, etc., not __spec__.__name__. And pre-existing code is going to change those values, so __spec__ is definitely not definitive.</div>

<div><br></div><div>As for mutating __spec__ to match other data after execution, I don't think that's needed. __spec__ should be viewed as a way to record what import worked with to make the import happen, but otherwise it's there because memory is cheap thanks to most systems not having many modules and it's better to log stuff unnecessarily than potentially toss out useful information. </div>

</div></div></div>