Scary. It means we have to be extra vigilant with larger system and functions. In the early days of C++ libraries had names like ACMECompanyRange().
So, Python won't help and it is the developers' job to watch out.
Scary. It means we have to be extra vigilant with larger system and functions. In the early days of C++ libraries had names like ACMECompanyRange().
So, Python won't help and it is the developers' job to watch out.
Namespaces are one honking great idea -- let's do more of those!
I agree 100%. However, is it used a lot?
There should be one—and preferably only one—obvious way to do it.
I don't agree, not at all. The software world is too complex for such a naïve assumption.
So, one can put functions and so on in modules which is good practice. System decomposition into independent and loosely coupled modules is recommended before jumping head first into coding marathons.
For example: if we want to overload range() we can put the code in a separate module and then just use it in client code as essentially a namespace, much like C++ and C#, for example.
Using modules and packages for program deccomposition.
The "Pythonic way" should not be a straightjacket/Procrustean bed. I think a Pytonic++ way deserves attention. These style guidelines transcend a given programming language.
A single style is not useful for all application domains? Motivation on why and when to use these Python rules would be good, otherwise it becomes somewhat robotic.
e.g. you might want to do things in Python that the Zen writers did not foresee.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.