> > > One point made about capabilities is that they partially go against the
> > > Pythonic grain.
...
> > If capabilities were implemented as Python references, you could inherit
> > capabilities (== references) from superclasses, just as you can currently do.
>
> That's why it says "shouldn't" instead of "couldn't". I could re-word
> this to go more along the way Ping phrased it in how the class statement
> does not make perfect sense for capabilities but it can be used.
I can't speak for Ping, but I would be quite surprised if he thought that
capabilities were un-Pythonic. (I wouldn't be surprised if he disapproved of
the notion of classes in a programming language, regardless of security
considerations...)
Speaking for myself, capabilities have two main advantages: they fit with the
Zen of Python, they enable higher-order least-privilege, and they fit with the
principle of unifying designation and authority.
But seriously, I feel that capabilities fit with normal Python programming as it
is currently practiced.
Regards,
Zooko
http://zooko.com/
^-- under re-construction: some new stuff, some broken links
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4