<div dir="ltr">On 14 January 2014 01:49, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="h5">On 14 January 2014 01:33, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>On 14 January 2014 01:06, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>

</div><div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>On 14 January 2014 00:44, Manuel Quiñones <span dir="ltr"><<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>></span> wrote:<br>


</div><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> We just need a way to know what is public API and what is not. Maybe, for<br><div>
> new code, everything is public unless it has the usual underscore or there<br>
> are inline docs mentioning it's not public. For old code well... I guess we<br>
> just decide case by case.<br>
<br>
</div>Yes, I think that's valid for old code too.  If you can import a<br>
class, function or constant variable from the toolkit, its public.<br>
</blockquote><div><br></div></div><div>Trying to make sure we are on the same page here, the devil is in details on this kind of stuff :)<br><br></div><div>* I think stuff prefix with _ is private, even if you can import it.<br>



</div><div>* I think it should be possible to mark stuff private by documentation. Maybe we should use a PRIVATE "keyword" so that it's more human and machine greppable. That's because sometimes you have modules that are only used internally, but you don't want to put _ everywhere.<br>



</div></div></div></div></blockquote><div><br></div></div><div>I suppose you could prefix the module with _, but I don't I've seen it done by other projects. <br></div></div></div></div>
</blockquote></div><br><br clear="all"></div></div></div><div class="gmail_extra">This is the PEP8 suggestion<br><br><a href="http://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces" target="_blank">http://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces</a><br>

<br></div><div class="gmail_extra">And I think it's also what python projects are usually doing. Problem is... we don't really write much documentation. I suppose we could enforce at least a single doc string explaining what the module does, for new code. But what about old code?<br>

<br></div><div class="gmail_extra">If there is agreement to follow PEP8 on this, I guess I could volunteer to write a quick description doc string for existing modules (other volunteers to do that are very welcome though :P).<br>

</div></div>
</blockquote></div><br></div><div class="gmail_extra">Uff I read too quickly<br><br>"Even with <tt class="">__all__</tt> set appropriately, internal interfaces (packages,
modules, classes, functions, attributes or other names) should still be
prefixed with a single leading underscore."<br><br></div><div class="gmail_extra">So we could use underscored modules.<br>
</div></div>