Python attributes, slots, and API design

Posted Jul 7, 2021 7:01 UTC (Wed) by LtWorf (subscriber, #124958)
Parent article: Python attributes, __slots__, and API design

I think it's funny how python is gradually becoming not python.

Annotating types, forbidding to add attributes to objects…

I understand the issue, but I think that if it's an issue for one object it can be an issue in any case. Not all the security issues are created miscalling ssl interfaces.

Python attributes, slots, and API design

Posted Jul 7, 2021 11:25 UTC (Wed) by vadim (subscriber, #35271) [Link] (1 responses)

I think that's a perpetual cycle of software development.

You start excited that it's nice and easy to just get stuff done without the compiler whining about something every 5 seconds. Life is good, code gets written fast.

Then a little project grows until there's 20 devs working on it. One day you spend hours figuring out that there's somebody made a typo and in one obscure user branch the code sets data['Username'] rather than data['username'] and this propagates through a bunch of layers until it explodes somewhere else entirely.

And then you start getting thoughts like "If I could have a hash with a fixed set of keys, or the compiler could check that for me, a lot of annoyance could have been avoided". And so you start grafting a way to get that done to your favorite language.

In my old age, I'm starting to develop the idea that writing anything big in something like Perl or Python may be a fundamentally bad idea -- you spend more time debugging issues that could have been avoided, and if you try to graft on checks afterwards it ends up that there are several slightly different and incompatible ways of doing it floating around.

Python attributes, slots, and API design

Posted Jul 7, 2021 19:43 UTC (Wed) by pj (subscriber, #4506) [Link]

>In my old age, I'm starting to develop the idea that writing anything big in something like Perl or Python may be a fundamentally bad idea

I tend to agree, if only because with python nothing should be 'big' - anything that might qualify should instead be broken into a bunch of modules, pulled together by a core that uses that functionality.

Python attributes, slots, and API design

Posted Jul 7, 2021 14:59 UTC (Wed) by pbryan (guest, #3438) [Link]

Every language undergoes evolution and Python even underwent an unpopular revolution: Python 3000 (aka. Python 3). If Python continues to evolve to meet greater and changing sets of needs, I'm all for it.

Python attributes, slots, and API design

Posted Jul 7, 2021 15:38 UTC (Wed) by mb (subscriber, #50428) [Link] (5 responses)

>I think it's funny how python is gradually becoming not python.

__slots__ and typing are optional.
It's up to you, as a developer, whether you use it or not.

Python doesn't become less Python, if optional features are added.

Python attributes, slots, and API design

Posted Jul 7, 2021 20:26 UTC (Wed) by Sesse (subscriber, #53779) [Link] (4 responses)

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.