[Python-ideas] Proposal: Use mypy syntax for function annotations

[Andrew Barnert]

On Aug 13, 2014, at 18:44, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> On 08/14/2014 01:26 PM, Andrew Barnert wrote:
> 
>> In Java or C++, it's… what? The sound option is a special JSONThing that
>> has separate getObjectMemberString and getArrayMemberString and
>> getObjectMemberInt, which is incredibly painful to use.
> 
> That's mainly because Java doesn't let you define your own
> types that use convenient syntax such as [] for indexing.

No it's not, or other languages like C++ (which has operator methods and overloading) wouldn't have the exact same problem, but they do. Look at JsonCpp, for example:

https://github.com/open-source-parsers/jsoncpp/

> Python doesn't have that problem, so a decent static type
> system for Python should let you define a JSONThing class
> that's fully type-safe while having a standard mapping
> interface.

How?

If you go with a single JSONThing type that represents an object, array, number, bool, string, or null, then it can't have a standard mapping interface, because it also needs to have a standard sequence interface, and they conflict. Likewise for number vs. string. The only fully type-safe interface it can have is as_string, as_number, etc. methods (which of course can only check at runtime, so it's no better than using isinstance from Python, and you're forced to do it for every single access.)

What if you go the other way and have separate JSONObject, JSONArray, etc. types? Then all of those problems go away; you can define an unambiguous __getitem__. But what is its return value? The only possibility is a union of all the various types mentioned above, and such a union type has no interface at all. It's only useful if people subvert the type safety by casting.  (I guess you could argue that returning a union type makes your JSON library type safe, it's only every program that ever uses it for anything that's unsafe. But where does that get you?) The only usable type safe interface is separate get_string, get_number, etc. methods in place of __getitem__.

Or you can merge the two together and have a single JSONThing that has both as methods and, for convenience, combined as_object+get, or even as_object+get+as_str.

Also, look at the mutation interfaces for these libraries. They're only marginally tolerable because all variable have obligatory types that you can overload on, which wouldn't be the case in Python.

The alternative is, of course, to come up with a way to avoid type safety. In Swift, you parse a JSON object into a Cocoa NSDictionary, which is a dynamically-typed heterogeneous collection just like a Python dict. There are C++ libraries with a bunch of types that effectively act like Python dict, list, float, str, etc. and try to magically cast when they come into contact with native types. That's the best solution anyone has to dealing with even a dead-simple algebraic data type like JSON in a static language whose type system isn't powerful enough: to try to fake being a duck typed language.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140813/53ef0e09/attachment.html>