pingu
Well-Known Member
There is no concept of namespaces in python. There is a concept of package but range is of the built-in functions. Built-in Functions — Python 3.8.0 documentation
-
Best online programming certificate for admission to MFE programs!
C++ PROGRAMMING for FINANCIAL ENGINEERING
(self-paced, up to 16 weeks, no prior programming required)
Python Questions
- Thread starter Daniel Duffy
- Start date
Daniel Duffy
C++ author, trainer
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.
So, Python won't help and it is the developers' job to watch out.
Last edited:
pingu
Well-Known Member
That's what unit tests are for.
Read this Code Style — The Hitchhiker's Guide to Python. specifically this part Code Style — The Hitchhiker's Guide to Python. This has been the mantra for the last 40 years. There is nothing new here.
Daniel Duffy
C++ author, trainer
Due diligence, thus.
BTW I always get a tummy pain every time I see the word 'Hitchhiker'.
I suppose the real issue in this case for me is that Python uses duck typing. OK.
BTW I always get a tummy pain every time I see the word 'Hitchhiker'.
I suppose the real issue in this case for me is that Python uses duck typing. OK.
Daniel Duffy
C++ author, trainer
I am browsing some 1-liners from Zen of Python
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.
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.
Daniel Duffy
C++ author, trainer
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.
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.
Last edited:
Daniel Duffy
C++ author, trainer
How is it possible to write well-designed and maintainable Python code?
What's your favourite method?
What's your favourite method?
It takes a lot of time and effort to get there. Obviously best practices from C++ carry over here as well, but some python specific
- Docstrings: help a lot in clearing the intent of author and at the same time can be invoked by the users!
- Unit testing: It helps in quickly checking if any code changes are giving expected results while refactoring
- Pythonic code: this one is pretty hard and takes time. You know good python code when you see it.
Daniel Duffy
C++ author, trainer
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.
Last edited: