Final classes and member functions

[dgoldstein0]

In some languages (e.g. java) it's possible to declare a class as final so that it can't be subclassed; similarly, it's possible to declare functions as final so that they can't be overridden by sublclasses. It would be great if typing could support this - so that classes could be annotated as final or their functions as final, and then tools like mypy could enforce it.

E.g.

@final
class Foo(object):
  pass

# type error
class Bar(Foo):
  pass

(reposting from python/mypy#2032)

[gvanrossum]

It's an interesting idea. In Python's past things like this have been proposed many times, but usually with the idea that a metaclass would have to be added that enforces it (like with `@abstractmethod`). I wonder if (like that) this should live in the `abc` module, possibly with an implementation that enforces it. But the type checker could still enforce it too. Alternatively it could live in typing and be purely a type checker feature. OTOH Wouldn't a comment (plus a note in any docs for the class) be just as effective? (Not, I guess, if you have an existing class or method that you want to change to be final -- the `@final` decorator would allow you to find any violations quicker than a grep, perhaps, and catch future violations.)

[dgoldstein0]

yeah, I really want this for the enforcement use case. I suppose failure
at runtime would work most of the time because classes are usually declared
in module scope but then you need some test that everything can be
imported; I suppose I'd trust a type checker to actually complain about all
usages in the case that I had some code which turned out not to be tested
at all.

On Wed, Sep 28, 2016 at 8:22 AM Guido van Rossum notifications@github.com
wrote:

It's an interesting idea. In Python's past things like this have been
proposed many times, but usually with the idea that a metaclass would have
to be added that enforces it (like with @abstractmethod). I wonder if
(like that) this should live in the abc module, possibly with an
implementation that enforces it. But the type checker could still enforce
it too. Alternatively it could live in typing and be purely a type checker
feature.

OTOH Wouldn't a comment (plus a note in any docs for the class) be just as
effective? (Not, I guess, if you have an existing class or method that you
want to change to be final -- the @final decorator would allow you to
find any violations quicker than a grep, perhaps, and catch future
violations.)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#286 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBnd0gmFYMjGgPL3qSGa-ZKMgLucTfdks5quoYfgaJpZM4KIyCv
.

[gvanrossum]

Given the (relative) uniqueness of your use case you're probably better off hacking your own metaclass. But I believe I've said that before. :-)

[dgoldstein0]

You have, but at the same time you suggested I come here to too

On Wed, Sep 28, 2016, 3:37 PM Guido van Rossum notifications@github.com
wrote:

Given the (relative) uniqueness of your use case you're probably better off
hacking your own metaclass. But I believe I've said that before. :-)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#286 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBnd00YXV6LLWmPtn0U89d4MzsHk5nTks5quuw0gaJpZM4KIyCv
.

[gvanrossum]

Yeah, so we can gauge interest.

[dgoldstein0]

At the moment I'm thinking it's probably easier to write a linter for my
use case. But of course if this became a mypy feature it'd be less code to
just use that.

On Wed, Sep 28, 2016, 7:34 PM Guido van Rossum notifications@github.com
wrote:

Yeah, so we can gauge interest.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#286 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBndy1STLj7yYEzrtbGvLisPrLipAxVks5quyPFgaJpZM4KIyCv
.

[elazarg]

final can be used similarly to the sealed feature in Scala, declaring a class to be only inheritable in the current file. this way the type checker can treat it as a Union over the subclasses (e.g. finding dead code, non-exhaustive overload/conditionals, more precise flow-sensitive recommendation etc.), without the need for awkward bookkeeping in a Union. In particular it will be suitable for Expression and Statement in mypy source code.

[JukkaL]

@elazarg I agree that the semantics you described would be nice.

[sobolevn]

I have released a utility library that can make classes final: https://github.com/wemake-services/final-class

[AgileInstitute]

The purpose of the sealed/final keywords is the same as making something in C++ nonvirtual: It allows you to improve the performance of a bottlenecked bit of code. As I understand it, method lookup in Python is always...well, a lookup. No performance benefit. So this run-time check is a rather weird, un-Pythonic hack.

Rather than creating a run-time failure to enforce something, I'd recommend providing the consumers of your class with some clear tests that give examples of how your code is to be properly used. If this is a team you have influence over, then perhaps provide some guidance via lunch-n-learn sessions, pair-programming, or mob-programming on basic OO principles, S.O.L.I.D., patterns wisdom (e.g., "Favor delegation over inheritance" --GoF), and Beck's Four Rules of Simple Design (e.g., "Testability trumps everything else, because everything else is made malleable through tests." -- me, just now).

[elazarg]

Final functions and classes allow you to reason better about the behavior of the program, making your program easier to understand. Being able to e.g. inline function calls is just one consequence.

This doesn't mean of course that runtime failures is the right way to implement such feature.