[Python-ideas] Adding jsonschema to the standard library

Andrew Barnert abarnert at yahoo.com
Sat May 23 07:07:34 CEST 2015


On May 22, 2015, at 19:59, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> 
> Donald Stufft writes:
> 
>> I think a future area of work is going to be on improving the
>> ability for people who don't know what they want to find out that
>> they want something and which thing they want on PyPI. I'm not
>> entirely sure what this is going to look like
> 
> +1
> 
>> but I think it's an important problem.
> 
> +1
> 
>> It's being solved for very specific cases by starting to have the
>> standard documentation explicitly call out these defacto standards
>> of the Python ecosystem where it makes sense.
> 
> Because that's necessarily centralized, it's a solution to a different
> problem.  We need a decentralized approach to deal with the "people
> who use package X often would benefit from Y too, but don't know where
> to find Y or which implementation to use."  IOW, there needs to be a
> way for X to recommend implementation Z (or implementations Z1 or Z2)
> of Y.
> 
>> This of course does not scale to every single problem domain or
>> module on PyPI so we still need a more general solution.
> 
> The only way we know to scale a web is to embed the solution in the
> nodes.  Currently many packages know what they use internally (the
> install_requires field), but as far as I can see there's no way for a
> package X to recommend "related" packages Z to implement function Y in
> applications using X.  Eg, the plethora of ORMs available, some of
> which work better with particular packages than others do.
> 
> We could also recommend that package maintainers document such
> recommendations, preferably in a fairly standard place, in their
> package documentation.  Even something like "I've successfully used Z
> to do Y in combination with this package" would often help a lot.
> 
> If a maintainer (obvious extension: 3rd party recommendations and
> voting) wants to recommend other packages that work and play well with
> her package but aren't essential to its function, how about a
> dictionary mapping Trove classifiers to lists of recommended packages
> for that implmenentation?

This is a really cool idea, but it would help to have some specific examples.

For example, BeautifulSoup can only use html5lib or lxml as optional HTML parsers, and lxml as an optional XML parser; nothing else will do any good. But it works well with any HTTP request engine, so any "global" recommendation is a good idea, so it should get the same list (say, requests, urllib3, grequests, pycurl) as any other project that wants to suggest an HTTP request engine. And as for scraper frameworks, that should look at the global recommendations, but restricted to the ones that use, or can use, BeautifulSoup. I'm not sure how to reasonably represent all three of those things in a node.

Of course it's quite possible that I jumped right to a particularly hard example with unique problems that don't need to be solved in general, and really only the first one is necessary, in which case this is a much simpler problem...



More information about the Python-ideas mailing list