[Proposal]: Deprecate Triple Dots (...) for Unimplemented Methods

[grandimam]

Motivation:

• Mojo aspires to be a seamless successor to Python++, adhering closely to Pythonic principles and fostering a positive experience for the Python community.
• The current practice of using triple dots (...) to denote unimplemented methods deviates from established conventions and can be confusing for Python developers.
• This inconsistency diminishes readability and creates a hurdle in the adoption process for those familiar with Python.

Proposed Solution:

• Eliminate the use of triple dots (...) for signifying unimplemented methods.
• Introduce two alternative approaches that align better with Pythonic practices:
• pass Statement: This is the recommended approach for simple unimplemented methods where no specific behavior is intended. It's a concise and Pythonic way to indicate that the method is a placeholder and needs further development.

trait Quackable:
  fn quack(self) -> String:
    pass
  
  @abstract
  fn walk(self) -> String:
     pass

• @abstract Decorator: This decorator can be employed for in case one doesn't want to use a pass keyword.

trait Quackable:
  @abstract
  fn quack(self) -> String
  
  @abstract
  fn walk(self) -> String

Benefits:

• Enhanced Readability: The code will become more consistent with Python conventions, improving comprehension and maintainability for developers.
• Streamlined Adoption: Developers familiar with Python will find the syntax more intuitive, reducing the learning curve and fostering faster Mojo adoption.
• Improved Developer Experience: A more Pythonic approach fosters a sense of familiarity and consistency, leading to a more enjoyable development experience for those accustomed to Python.

[lsh]

Traits are equivalent to Protocols in Python, and the ... is explicitly the way the Protocol PEP specifies a trait being unimplemented. The difference is arguably that pass implies that the method just doesn't do anything (once default trait implementations are available), whereas ... is more of a TODO.

ETA:
I personally am fine with a more explicit way to raise a not implemented error that doesn't require adding raises to the signature.

[grandimam]

How? Can you point me to the exact line or phrase in the proposal where it is mentioned to use of three dots (...) for defining a Protocol. The below code is also a completely valid way of achieving the same thing:

from typing import Protocol

class Flyer(Protocol):
    def fly(self) -> None:
      """A Flyer can fly"""

Something like this also makes sense:

from typing import Protocol
from abc import abstractmethod

class Example(Protocol):
    def first(self) -> int:     # This is a protocol member
        return 42

    @abstractmethod
    def second(self) -> int:    # Method without a default implementation
        raise NotImplementedError

[lsh]

Ah I think you might be right about it not being explicitly part but just used in the examples. On the topic of abstractmethod I'm a little on the fence. Trait methods will be able to have a default implementation, but they are inherently abstract. You can't store a trait in a variable, only a type that conforms to a trait

[grandimam]

Agreed! I just want to better way of representing the unimplemented methods. I believe that using three dots (...) is more like a kludge and threw me off completely.

[soraros]

The current practice of using triple dots (...) to denote unimplemented methods deviates from established conventions and can be confusing for Python developers.

You might prefer pass, but I really don't see how ... can be confusing: the fact that most examples in PEP 544 uses ... is pretty telling. If you look at any .pyi file, you shall see that they are used to indicate the lack of a body. Inside these type studs are function prototypes which lacks the concept of a body and only happen to have the same syntactic form of a function. I would argue that Mojo is pretty consistent with this very established use in Python. In contrast, pass indicates more the existence of an empty body (empty except clause), which is different.

pass Statement: This is the recommended approach for simple unimplemented methods where no specific behavior is intended. It's a concise and Pythonic way to indicate that the method is a placeholder and needs further development.

To quote your own words: can you point me to the exact line or phrase in the Python manual where it is mentioned to use pass over ... as a placeholder?

@abstract Decorator

Things in traits are "abstract" by default. Besides, people opt to use @abstractmethod with raise NotImplementedError() because there isn't a good way to check for missing implementation without a type checker like pyright or mypy. I see it as a way to work around Python's own "shortcomings".

[rarebreed]

I do have a slight concern about using ... but for a different reason. I also disagree with pass for the same reason I disagree with .... And since mojo will eventually get default implementations, @abstract can just be the default with an "empty" body. It;s actually the syntax for the "empty" body that is a problem.

My concern is that there could be a disconnect in meaning between python and mojo's ... Ellipsis for python programmers.

In python, the Ellipsis isn't just a placeholder; it's an actual constant that has a value. It's a special value that can be used and interpreted by python in different ways (eg slicing syntax), but it is still an actual value. In python, you can invoke this:

def try_me():
    ...
try_me()

Mojo seems to be using ... as special magic syntax for "throw a compiler error if the struct doesn't implement this method at compile time". It diverges from python's meaning, so that is my concern. But the same problem exists with using pass. So, how else can we declare an empty body?

The compile time in bold is important. struct types must be fully available once the program is up and running. You can't dynamically add function implementations at runtime on a struct. However, I do think mojo should use the ... syntax once they implement a class type, because then it would be just like what a python programmer would expect.

I am also curious how trait is going to interact with python's Protocol? How will method resolution order happen when you have a mojo class that implements both a Protocol and a trait? Or will trait only be allowed for struct types? I am sort of thinking it will be that, because trait will also allow you typeclass/extension capabilities (like hashell typeclasses, rust traits, or swift/kotlin/scala extensions). And having traits with extensions with MRO will be really messy I think.

So, I think mojo still needs to be fleshed out a bit more.

[soraros]

You can call try_me in Mojo just fine.

I'd argue that ... is magic syntax for the "empty body" (ε) (in the correct contexts). I see the fact that ... being (the syntax for) a constant in Python more to make the implementation simpler. They get special treatment like purely syntactic form even in Python, for instance, we don't get "unused value" warning from type checkers when used in function body. I don't think people will argue that the following express the same intent:

def f():
  ...

# This is just silly
def f():
  Ellipsis()

Mojo seems to be using ... as special magic syntax for "throw a compiler error if the struct doesn't implement this method at compile time".

Compiler raising errors for missing function for trait conformance is a separate thing from how trait declarations look like. But I guess you were talking about disambiguating function with a default empty implementation from function declaration which looks the same?

P.s. I'm more surprised that as a Rust expert, you didn't push for something like this (which has its own set of tradeoffs).

trait T:
  fn f(self) -> T

[rarebreed]

Compiler raising errors for missing function for trait conformance is a separate thing from how trait declarations look like. But I guess you were talking about disambiguating function with a default empty implementation from
function declaration which looks the same?

Yeah, it's the disambiguation I am a little concerned about. Not a lot, but I think if enough of these special cases pop up, the more overload it will be to remember. I think the ... is ok, because it's already known by python programmers as a kind of "todo" or placeholder.

P.s. I'm more surprised that as a Rust expert, you didn't push for something like this (which has its own set of tradeoffs).

trait T:
  fn f(self) -> T

Oh, I am not a rust expert :) Some async stuff pulls my hair out. And that's not even getting into GAT's yet. But going with your syntax, I'd be ok with that, If you look at it, that is already the type itself of a callable. Makes sense to me :)

[nmsmith]

I'm not a huge fan of ... (it's quite a bizarre and unprincipled token, IMO), but it seems to be the best choice if we are imposing the constraint that Mojo should reuse a syntax that already exists in Python.

I would also be satisfied if Mojo were to introduce a new keyword that means no_implementation, and which is not a value.

[lattner]

This proposal seems like a pretty clear "no", in that it breaks from the core principles of what Mojo is about. We aren't trying to be a similar-but-different language to Python, we are building into a full superset over time. If you don't like ..., I'd suggest taking it up with the Python community. Am I misunderstanding your proposal here?

[ivellapillil]

Don't we already have Traits that is static counterpart of Protocol? Does Mojo need to support Protocol other than probably for the meta data at runtime? Probably no-op except for the meta data?

[rarebreed]

Don't we already have Traits that is static counterpart of Protocol? Does Mojo need to support Protocol other than probably for the meta data at runtime? Probably no-op except for the meta data?

For mojo to be a true superset, it will need to support python's Protocol (but probably on a future class type). In other words, mojo doesn't have to support Protocol on a struct, but it will have to on a future class. My question is will mojo's trait only work on struct types, or will it also work on a future class type?

If the latter, then traits will have to interact with Protocol (and multiple inheritance in general).

The ... thing is valid in the dynamic use case for python. And if mojo wants to be a 100% compatible version of python, then it must be allowed in the implementation body. My concern therefore, is that now you have to remember "oh yeah for traits, in a struct, ... is illegal in the implementation body, but in a class, ... is legal`. The question is, will this be allowable in (a future version of) mojo?

from collections import Optional

trait Reader:
    def read(self, source: String) -> Optional[String]: ...

class S3Path(Reader):
    def read(self, source: String) -> Optional[String]:
        ...  # if traits are allowed on a class, then this should compile and be legal

If traits are not allowed in a (future) class type, then all of these concerns go away. That's why I actually vote for not allowing traits in a mojo class. Either you have static dispatch with a struct + trait, or you do dynamic dispatch with a class + Protocol/multiple inheritance/mixin. And of course, mojo can get dynamic dispatch too, if it does something like rust's dyn Trait

[ivellapillil]

Actually I would like to have class and struct be both first class and supported by Traits. Otherwise, generic algorithms that depends on Traits will not work for classes, dividing the codebase into have and have-nots. I strongly prefer that Traits apply to both struct and class.

Additionally, structs and classes ideally would be having same capabilities, but just different defaults. Similar to the fn and def where the defaults are different, but fn can be defined to be exactly like def if desired.

This means that structs can also have dynamic dispatch, probably with annotation @dynamic, whereas classes would be by default @dynamic.

This means we need to have the concepts of Protocol and Traits aligned well together. I think we are on the way with that as now Mojo supports automatic implementation of traits if the required methods are implemented, without having to explicitly specify it in the struct.

def read(self, source: String) -> Optional[String]:
        ... 

The above code actually should fail in Mojo because from a static compilation point of view, it is wrong (it does not return what it claims to return). Here a deviation from Python is expected anyway due to static typing nature of Mojo...

[rarebreed]

Actually I would like to have class and struct be both first class and supported by Traits. Otherwise, generic algorithms that depends on Traits will not work for classes, dividing the codebase into have and have-nots. I strongly prefer that Traits apply to both struct and class.

trait is supposed to eventually get parameters, so that will enable generic algorithms in traits for struct. They will also eventually get an extension feature, which is how rust's traits and scala/kotlin extensions work (swift has them too, but I've never done swift). For a trait, it will allow one to add its contract to a pre-existing struct which will help make up for the struct lack of dynamism.

I agree that would be nice if a mojo author only had to create trait types, so they could reuse them for class types as well and not think in terms of multiple inheritance. But mojo already lives in a "have and have nots" world. struct exists for performance in a compile time world with limited to no dynamism (it could get something like rust's dyn Trait). A class has to exist to support python fully, but that also means that it will (potentially) suffer in performance.

As far as I can surmise, there must be a difference between a trait and just implementing a struct as an abstract base class with an @abstractmethod on the fn. As far as I have heard, there are no plans to implement multiple inheritance for struct. That and the ability for a trait to do extensions tells me that it is designed for compile time behavior.

Could a trait be interpreted by a class as just another class but only with methods? Probably? Mojo could probably reify a trait into something for the class to use. If mojo can build a .dll/.so extension that can be imported by python, I think it would need some kind of flag to tell the compiler how to reify a trait into something real that the python interpreter can use.

Imagine you have two mojo modules, one defining a trait, the other has a class. And the class gets extended by the trait. Imagine some kind of syntax like this (I have no idea what it will be, but hopefully this kind of makes sense)

# in file reader_trait.mojo
from collections import Optional

trait Reader:
    def read(self, source: String) -> Optional[String]: ...

# in file s3path.mojo
# something like this ABC will be required to be 100% compatible with python
from abc import ABC, abstractmethod
from reader_trait import Reader
from collections import Optional

class Path(ABC):
    @abstractmethod
    def read(self, src: String) -> Optional[String]:
        ...

# Imagine class supports traits and this is the syntax for trait extensions.  Will this be allowed?  Can we 
# implement  and extend an ABC type with a trait?
implement Reader for Path:
    def read(self, source: String) -> Optional[String]:
        ... # Do something real here, not just ellipsis

# Logically, this _should_ work.  We extended class Path to have an implementation.  But python would 
# require  S3Path to implement the read function.  This will be confusing to python programmers because
# it should not be allowed, but for a mojo programmer it logically should be allowed
class S3Path(Path):
    ...

I think it's possible trait can be implemented for a class, but I think it would be confusing to have both trait and Protocol especially for existing python programmers who will be forced to learn what a trait is if a class is subclassed by a trait.

So, I think it's technically possible, but I'm a bit leery that

• ... in the body of a method will be valid for class but not for struct
• There will (possibly) be a divergence in trait between what it means for struct and class

[rarebreed]

Additionally, structs and classes ideally would be having same capabilities, but just different defaults. Similar to the fn and def where the defaults are different, but fn can be defined to be exactly like def if desired.

This means that structs can also have dynamic dispatch, probably with annotation @dynamic, whereas classes would be by > default @dynamic.

There is already a proposal for class on whether the default should be full hash-table like dynamism, or something more limited. However, that's only proposed for the future class type. There's no discussion on something similiar for struct

So I don't think a struct can or should basically be the same as a class but with different defaults.

• Why have struct if it's just just class with @strict (or the converse, class is just a struct with @dynamic?)
• Dynamism is more than just static vs dynamic dispatch
• fn and def aren't just different by default, def is the only one that allows variables to be declared without var to handle python function scoping

Mojo is a compile time language whereas python is a runtime language. In order to do things faster, there needs to be a limit on what a struct can do. For example, one wouldn't be able to dynamically add fields or methods to a struct. So having an annotation wouldn't really make sense because some things should be entirely disallowed for a struct.

Also, in python a class is just a kind of container that can execute code anywhere in the body. This is valid python (bad python, but still valid)

class Foo:
    # if you don't like random, replace this with a function call that can return different int values
    x = randint(0, 10)  
    if x > 5:
        class Bar:
            def run(self) -> int:
                return Foo.x * 2
    else:
        class Bar:
            def show(self):
                print(f"Bar did something with {Foo.x}")
    def execute(self):
        bar = self.Bar()
        return bar

f = Foo()
b = f.execute()
# does b have the run or show method?
b.run()

How would the mojo compiler handle this if that could be done for a struct? Every time it compiled the code, depending on what randint(0, 10) returned, it would generate a different binary.

A struct also would not be able to add fields at runtime without adding (signifcant) overhead to performance. I suppose you could add a @dynamic annotation, but then a one line change would invalidate a lot of code. A struct is fast because it has a known size that will always be true. This means it can work with things like pointer offsets, or being able to have a struct that is @register_passable.