<div dir="ltr">Hi all,<div><br></div><div>After to read all responses, I've changed my mind:</div><div>At the first look, the advantage to push jsonschema into Python lib is to standardize and promote an actual good practice.</div><div>But yes, you're right, it's too early to include that because the standard should be changed and/or abandonned by a new good practice, like SOAP and REST.</div><div><br></div><div>It's more future proof to promote PyPI and pip to Python developers.</div><div><br></div><div>Regards.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>--<br><div style="font-size:small"><div>Ludovic Gasc (GMLudo)</div></div><div style="font-size:small"><a href="http://www.gmludo.eu/" target="_blank">http://www.gmludo.eu/</a></div></div></div></div></div>
<br><div class="gmail_quote">2015-05-23 16:21 GMT+02:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 23 May 2015 at 12:59, Stephen J. Turnbull <<a href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>> wrote:<br>
> Donald Stufft writes:<br>
</span><span class="">>  > It's being solved for very specific cases by starting to have the<br>
>  > standard documentation explicitly call out these defacto standards<br>
>  > of the Python ecosystem where it makes sense.<br>
><br>
> Because that's necessarily centralized, it's a solution to a different<br>
> problem.  We need a decentralized approach to deal with the "people<br>
> who use package X often would benefit from Y too, but don't know where<br>
> to find Y or which implementation to use."  IOW, there needs to be a<br>
> way for X to recommend implementation Z (or implementations Z1 or Z2)<br>
> of Y.<br>
<br>
</span><a href="https://www.djangopackages.com/" target="_blank">https://www.djangopackages.com/</a> covers this well for the Django<br>
ecosystem (I actually consider it to be one of Django's killer<br>
features, and I'm pretty sure I'm not alone in that - like<br>
ReadTheDocs, it was a product of DjangoDash 2010).<br>
<br>
There was an effort a few years back to set up an instance of that for<br>
PyPI in general, as well as similar comparison sites for Pyramid and<br>
Plone, but none of them ever hit the same kind of critical mass of<br>
useful input as the Django one.<br>
<br>
The situation has changed substantially since then, though, as we've<br>
been more actively promoting pip, PyPI and third party libraries as<br>
part of the recommended Python developer experience, and the main<br>
standard library documentation now delegates to <a href="http://packaging.python.org" target="_blank">packaging.python.org</a><br>
for the details after very brief introductions to installing and<br>
publishing packages.<br>
<span class="im HOEnZb"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</div></div></blockquote></div><br></div>