I think that we should support the linked data use case with at least: 1. a __json__(obj, spec=None) method and 2. a more-easily modifiable make_iterencode/iterencode implementation in the json module of the standard library.
On Wed, Apr 8, 2020 at 5:00 PM Andrew Barnert <abarn...@yahoo.com> wrote: > On Apr 8, 2020, at 12:55, Wes Turner <wes.tur...@gmail.com> wrote: > > > > We should welcome efforts to support linked data in Python. > > Fine, but that’s doesn’t meant we should derail every proposal that has > anything to do with JSON by turning it into a proposal for linked data, or > consider a useful proposal to be useless because it doesn’t give us linked > data support on top of whatever it was intended to give us. > > > No one cares whether you believe that "semantic web failed" or "those > standards are useless": > > But no one is saying either of those things. People are saying that the > semantic web is irrelevant to this discussion. JSON is useful, JSON Schema > is useful, improving Python to make working with ad hoc or Schema-specified > JSON is useful, and that’s all equally true whether the semantic web is the > one true future or a total failure. > > Would a __json__ method protocol improve Python? I don’t think so, but the > reasons I don’t think so have nothing to do with LD. Other people do think > so, and their reasons also have nothing to do with LD. And the same is true > for most of the counter- and side-ideas that have come up in this thread > and the last one. > > > re: generating JSON schema from type annotations > > > > You can go from python:Str to jsonschema:format:string easily enough, > > but, again, going from python:str to jsonschema:format:email will > require either extending the type annotation syntax or modifying a > generated schema stub and then changes to which will then need to be ported > back to the type annotations. > > Sure, but who says you have to store email addresses as str? > > @dataclass > class Person: > name: str > email: Email > address: Address > > The fact that str is a builtin type, Address is a dataclass with a bunch > of builtin-typed attributes, and Email is (say) a str subclass (or a > dataclass with just a str member or whatever) that knows to render to and > from type:string, format:email instead of just type:string doesn’t change > the fact that they’re all perfectly good Python types and can all be used > as type annotations and can all be mapped to a JSON Schema. How does it > know that? Lots of things would work. Which one you use would be up to your > JSON Schema-driven serialization library, or to your > Python-code-from-JSON-Schema generator tool or your static Schema-from-code > generator tool or.whatever. Maybe if we have multiple such libraries in > wide use fighting it out, one of them will win. But even if there’s never a > category killer, any of them will work fine for the applications that use > it. > > And of course often just using str for email addresses is fine. There’s a > reason the Formats section of the JSON Schema spec is optional and > explicitly calls out that many implementations don’t include it. And in > some applications it would make more sense to break an email address down > into two parts (user and host) and store a dict of those two values > instead, and that’s also fine. Would it better serve the needs of the > semantic web if the email format were a mandatory rather than optional part > of the spec and everyone were required by law to always use it when storing > email addresses? Maybe. But neither of those things are true. > > >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EDWP54EOMECBKUIDWZMU5Q4ADSI36Z27/ Code of Conduct: http://python.org/psf/codeofconduct/
