<div class="gmail_quote">On Sat, Nov 26, 2011 at 11:53 AM, Éric Araujo <span dir="ltr"><<a href="mailto:merwok@netwok.org">merwok@netwok.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> Le 11/08/2011 20:30, P.J. Eby a écrit :<br>
>> At 04:39 PM 8/11/2011 +0200, Éric Araujo wrote:<br> >>> I’ll just regret that it's not possible to provide a module docstring<br>
>>> to inform that this is a namespace package used for X and Y.<br>
>> It *is* possible - you'd just have to put it in a "zc.py" file. IOW,<br>
>> this PEP still allows "namespace-defining packages" to exist, as was<br>
>> requested by early commenters on PEP 382. It just doesn't *require*<br>
>> them to exist in order for the namespace contents to be importable.<br>
<br>
That’s quite cool. I guess such a namespace-defining module (zc.py<br>
here) would be importable, right?</blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Also, would it cause worse<br>
performance for other zc.* packages than if there were no zc.py?<br></blockquote><div><br></div><div>No. The first import of a subpackage sets up the __path__, and all subsequent imports use it.</div><div><br></div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">>>> A pure virtual package having no source file, I think it should have no</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
>>> __file__ at all.<br>
<br>
Antoine and someone else thought likewise (I can find the link if you<br>
want); do you consider it consensus enough to update the PEP?<br></blockquote><div><br></div><div>Sure. At this point, though, before doing any more work on the PEP I'd like to have some idea of whether there's any chance of it being accepted. At this point, there seems to be a lot of passive, "Usenet nod syndrome" type support for it, but little active support.</div>
<div><br></div><div>It doesn't help at all that I'm not really in a position to provide an implementation, and the persons most likely to implement have been leaning somewhat towards 382, or wanting to modify 402 such that it uses .pyp directory extensions so that PEP 395 can be supported...</div>
<div><br></div><div>And while 402 is an extension of an idea that Guido proposed a few years ago, he hasn't weighed in lately on whether he still likes that idea, let alone whether he likes where I've taken it. ;-)</div>
<div><br></div></div>