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/QTDOOH4ASKWNUFYRZHUOSNQB62MAL5YK/
Code of Conduct: http://python.org/psf/codeofconduct/
