• 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

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.
 
Last edited:
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.
 
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.
 
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.
 
Last edited:
How is it possible to write well-designed and maintainable Python code?
What's your favourite method?
 
How is it possible to write well-designed and maintainable Python code?
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.
 
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:
Stumbled on TurtleGraphics

Serious, just seen that Python supports Turtle Graphics. I used it on an Apple II way back to create business graphics package for project managements. Low level but it could do anything (output to shlow matrix printers).
turtle — Turtle graphics.


Sample (flashback>>)

import turtle
import time

c =turtle.Turtle()
c.getscreen().bgcolor("black")
c.color("red","yellow")
c.begin_fill()
c.fd(100)
c.lt(120)
c.fd(100)
c.lt(120)
c.fd(100)
c.end_fill()

time.sleep(10)
 
Back
Top