Here's a sample from VS Code of the type hinting and docstring preview

All the tests failing 😆 I know this will go no where without being able to pass the CI tests, but like I mentioned, it's more of a conceptual starting point.

Going to add some tasks to the original PR comment that pertain to some of the CI test failures.

@Burhan-Q would it be possible to just expand the arguments in model and read the defaults directly from the YAML, i.e. something like:

args = read from default.yaml here

def train(imgsz: int = args["imgsz"],
...

EDIT: No I guess not:

@glenn-jocher as far as I'm aware, the type hinting is all done statically, so we can't use the YAML values. This was something I thought about and tried, but wasn't able to and couldn't find a way make work.

From what I understand from reading/research on this topic, is that in an ideal world, the code would be sufficient to be "self-documenting." That would mean that artifacts (like the default.yaml) shouldn't be necessary. I'm not saying that it should be removed, only saying that my understanding is that it shouldn't be relied on as it's "external" to the source code.
This is the same idea of not having information replicated, but takes it one step further by ensuring it's the source code that is "the single source of truth" and removes reliance on any external artifact. We can create artifacts like default.yaml and the documentation from the source code, but my understanding is that generally you don't want to try to generate code/logic from these artifacts (at least not partially).

If we use something like this concept, the ModelMeta class becomes the definitive source of truth as far as what's permitted into the high-level methods of the model. These get passed down to the other model inherited classes as needed. It would also mean that it would be the source to generate whatever artifacts or documentation needed (and I'm not claiming that what I have here is perfect or even close to the "correct" way to achieve this).

My thinking is that (for this implementation at least), we could generate the new default.yaml file from the ModelMeta class, but still make things backwards compatible with the old format. This would also mean that the argument checking done under the cfg/__init__.py would have to be modified, and I haven't thought about how (or if) it's feasible to make this backwards compatible as well. Really, moving all the arguments to a class like this would mean that all the "checks" for correct arguments could be offloaded to the python interpreter (which might make things quicker), but off the cuff, if we generate a default.yaml from the ModelMeta class, then the same checks could be run with an accounting for the change in structure.

Hi @Burhan-Q !
Can I contribute in this task? Where can I start?

👋 Hello there! We wanted to let you know that we've decided to close this pull request due to inactivity. We appreciate the effort you put into contributing to our project, but unfortunately, not all contributions are suitable or aligned with our product roadmap.

We hope you understand our decision, and please don't let it discourage you from contributing to open source projects in the future. We value all of our community members and their contributions, and we encourage you to keep exploring new projects and ways to get involved.

For additional resources and information, please see the links below:

• Docs: https://docs.ultralytics.com
• HUB: https://hub.ultralytics.com
• Community: https://community.ultralytics.com

Thank you for your contributions to YOLO 🚀 and Vision AI ⭐