mojo
mojo copied to clipboard
modularml
[BUG] Divergences in Standard Library naming conventions
Bug description
Python has a lot of problems left over from the previous era connected to naming which cannot be fixed due to compatibility reasons. Mojo as new language should has unified convention but it does the same divergences as Python in Testing and instead of snake_case for methods it uses camelCase:
- assertEqual
- assertAlmostEqual
Mojo has a great opportunity to fix that problems and be consistent in naming convention, so:
- assertEqual should be assert_equal
- assertAlmostEqual should be assert_almost_equal etc.
Steps to reproduce
-
System information
No response
@gryznar The unittest unit testing framework was originally inspired by JUnit. I don't believe it will change in the future, and it's not ideal to deviate from the xUnit unit testing framework family.
I see, but this is very unpythonic and I do not see the point why Mojo can't just have done it a better way. I am aware that it was inspired by java-like style but it is the source of truth for it? It seems very odd, that a lot of things in Python heavily inspired by other language has snake_case or PascalCase style which is consistent and only testing or logging library has not.
One more thing to add here. In Python pytest is much more popular than unittest and it uses classic convention for that. So it is really big deal, that Mojo will just be consistent and do not introduce camelCase only in one file? I don't think so.
I like very much that Mojo does a lot things in a much better way than previously was done, so this incostistency is a much more visible. If someone would like to use jUnit style he can just import unittest from pytest and will have very similar experience.
Python may stick to java-like style, but why Mojo stick also? To be clear, I am referring to Mojo Testing lib: https://docs.modular.com/mojo/MojoStdlib/Testing.html
@gryznar Quoting from Why Mojo:
Further, we decided that the right long-term goal for Mojo is to provide a superset of Python (that is, to make Mojo compatible with existing Python programs) and to embrace the CPython implementation for long-tail ecosystem support.
Supporting the Python Standard Library is crucial.
But Testing is Mojo's library, not Python's, so what's the point here? Sorry, I don't understand that. If am I not wrong, Mojo can name methods, structs etc in its own libraries how it wants and this do not break compatibility with Python. Could you please explain that because it is unclear to me.
@gryznar Mojo's long-term goal is to achieve compatibility with existing Python programs, e.g., running a Python unittest in Mojo without relying on CPython.
While it is beneficial to adhere to Python PEP 8 (though not mandatory), it's worth noting that Mojo currently does not have any specific naming convention.
But that's not the case of compatibility. In Python there is:
unittest.TestCase.assertEqual
In Mojo:
Testing.TestSuite.asssertEqual
so, in case of separate libraries, there is no technical obstacles (in my opinon) to have:
unittest.TestCase.assertEqual (bind to CPython somehow) and Testing.TestSuite.asssert_equal directly from Mojo
Is this jUnit legacy as important to have one file different especially because of it? Python has adopted a lot of things from different languages, but mostly it does not name it with original language's style, but it addopts it to its own style. Two exceptions are unittest and logging. Has Mojo follow this "tradition"? I really don't think so.
Mojo is considered as superset of Python, so that implies, that its naming convention will be follow Python rules and PEP8. If unittest will have possibility to be rewritten will Python still have it in camelCase? I don't think so. Moreover a lot of things in Python which were camelCase were deprecated and renamed to snake_case.
I have open a topic on Python ideas to just give a feedback what Python developers could do if they would have the possibility to start unittest from scratch: https://discuss.python.org/t/snake-case-aliases-to-camelcased-methods-in-unittest/27381/4 and I got this answer from Core Python developer:
Mojo is in this place, where it can change it within its own Testing.TestSuite struct.
You're right, we haven't been very careful with the definition of api's and auditing their names etc, we should fix them to be consistent. @abduld can you ask someone to fix these up? Thx
Yes, we are in the process of auditing the names and making sure they are more closely aligned with Python
2 weeks have passed and this trivial fix is still not implemented unfortunately :(
sorry, but we do want python naming compatibility in this case. It's unfortunate that python did not follow the snake case convention here
But if Python would have occasion to choose one more time it would choose snake case. I have a long, long talk about this and we are still at starting point? Really? Chris Lattner said sth different about this, so this does not change anything? Really?
What are advantages of this compatibility? I really don't know why Mojo would like to do the same mistake which cannot be undo in Python.
I have posted a screenshot with statement from Core Python developer which says, that if they just have occasion to choose one more time, they would choose snake case. It is that not enough?
Please, share only one argument, why this "compatiblity" is so important here.
sorry, but we do want python naming compatibility in this case. It's unfortunate that python did not follow the snake case convention here
It's because unittest predates PEP8. https://peps.python.org/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
If someone would like to use Python code directly in Mojo, he cannot just copy-paste existing tests. He has to adjust inheritance and import : unittest ->Testing and TestCase -> TestSuite, so what is the problem to adjust also assertions and get rid off this awful camelCase here?
@gryznar Two notable aspects are search friendliness and method overloading. For example, you can easily search using a single method name like "assertEqual". When dealing with thousands of pages of documentation and millions of lines of code, CTRL+F becomes your closest ally.
If someone would like to use Python unittest he can just import unittest. That's not the point here. A lot of custom methods in Mojo will have different name than in Python.
Searching for methods happens only few times. This is not repeatable process. If someone would search for phrase: "assert" the result will point both to assertEqual and to assert_equal. Python users in most cases are using pytest and not legacy unittest.
People in most cases would appreciate Mojo, that incosistent name are fixed. You can make a pool and ask people if they want names compatible in 100% with Python or consistency. I can assume that people rather than being happy due to finding method "assertEqual" in Mojo would think: "Mojo did the same shit as Python..."
Here I've posted all arguments: https://github.com/modularml/mojo/discussions/384
it looks like the way forward is to not pretend that the Mojo testing is compatible with Python testing package and consistently use snake case. I am not against that @gryznar and thanks for raising this
Great to hear that! Sorry for emotions, but consistency really matters not only for me :)
No problem :) If you would like to get used to snake_case, there is also separate issue to fix that convention in documentation. :)