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
-
C++ Programming for Financial Engineering
Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!Python for Finance with Intro to Data Science
Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!An Intuition-Based Options Primer for FE
Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!
Python Questions
- Thread starter Daniel Duffy
- Start date
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:
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.
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.
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.
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:
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.
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:
