Python attributes, slots, and API design

Posted Jul 7, 2021 20:26 UTC (Wed) by Sesse (subscriber, #53779)
In reply to: Python attributes, __slots__, and API design by mb
Parent article: Python attributes, __slots__, and API design

Programming languages are not primarily about their language definition, but by their culture. If everyone ends up using Python types, then Python programming will effectively be different: You can try to go against the grain and not use them, but every other programmer will look funny at you, every library you interface with will require them, all documentation and sample code you can find will use them. It doesn't matter how optional the interpreter says they are; Python as a language has still changed. (Whether you consider programming with static typing “less Python” or not is a different question, of course.)

Python attributes, slots, and API design

Posted Jul 7, 2021 20:42 UTC (Wed) by mb (subscriber, #50428) [Link] (3 responses)

>every library you interface with will require them

That's not how typing works in Python.

Python attributes, slots, and API design

Posted Jul 7, 2021 21:52 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (2 responses)

Just as a refresher for anyone who hasn't been following this, Python's static typing essentially consists of the following:

* Optional syntax for annotating the types of things. The interpreter treats this syntax as a glorified comment. It checks for basic syntactic validity and NameError, and that's about it. If you say that the type of an object is "12", or don't indicate a type at all, the interpreter is perfectly happy with that. If you write a syntax error, it will yell at you, but that's hardly a problem since you can just omit annotations altogether.
* The typing module, which includes a number of classes that let you write things like Union[foo, bar] or Optional[T]. The resulting objects are (for the most part) just opaque blobs that have reasonable-looking repr() text. They generally don't have any actual logic in them, and are just designed to remember the arguments you passed in.
* A set of linting rules for checking the types of things. CPython itself does not include a reference implementation of those rules, so the CPython interpreter is incapable of applying them. Instead, you have to download a third-party linter such as mypy. Obviously, the linter will be unhappy if an object's type is "12", but if you're running the linter, then you presumably wanted to be warned about that... right?

Hypothetically, if the entire Python community decided tomorrow that all new code must have static types, then the only problem you would have is that some people would file bugs against your project saying the linter doesn't like it. You can WONTFIX those bugs and carry on as usual, if that is your inclination. There should be no compatibility issues with anyone else's code. If you write library code, and your library is unannotated, then some people might be unhappy about that (because it would make the linter less accurate on their application code where it calls into your library), but that's arguably their problem, not yours.

(If you want, you can provide a set of type hints for your external API without having to type hint every line of code inside your library. This is particularly useful for C extensions, which otherwise would not be possible to annotate.)

Python attributes, slots, and API design

Posted Jul 7, 2021 23:03 UTC (Wed) by Sesse (subscriber, #53779) [Link] (1 responses)

I am fully aware, but it's also missing my point. Yes, you can ignore whatever you'd like and code in your own little corner. You can also write Python with braces and have a preprocessor convert them into the right indentation. But at some point, that's going to be culturally very much uphill. (I guess I should have picked a different example than types.)

Python attributes, slots, and API design

Posted Jul 7, 2021 23:30 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

Seeing as this whole discussion was already about types to begin with, I frankly fail to understand what kind of point you were trying to make in the first place.