Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
Datasette currently has a few API internals that return sqlite3.Row objects. I was thinking about how this might work in the future - if Datasette ever expands beyond SQLite (plugin-provided backends for PostgreSQL and DuckDB for example) I'd want a way to return data from other stores using objects that behave like sqlite3.Row but are not exactly that class.
It’s very weird to me that Python, as an inherently untyped language
I don’t think this is true. Python is dynamically typed, but types exist. More importantly, Python is the poster child of duck typing. What is duck typing if not a way to implicitly specify protocols? If you’re relying on protocols to work, why not have tests for it? If you want to test protocols, aren’t you actually doing type checks?
If typing is a good thing,
…which undoubtedly is.
(…) why not make it an optional first-class part of the language?
It already is, isn’t it?
But some people already have Python code that does not do type checking. What would be the point of refusing to run that code?
I don’t think this is true. Python is dynamically typed, but types exist. More importantly, Python is the poster child of duck typing. What is duck typing if not a way to implicitly specify protocols? If you’re relying on protocols to work, why not have tests for it? If you want to test protocols, aren’t you actually doing type checks?
…which undoubtedly is.
It already is, isn’t it?
But some people already have Python code that does not do type checking. What would be the point of refusing to run that code?