Well I love python, but this reminds me of a set of an old paper by Peyton-Jones of GHC fame, which developed a Haskell combinator lib that did something like this. I'm sure the state of the art has left this system long behind, but it's a pretty interesting concept.
Composing contracts: an adventure in financial engineering, Simon Peyton Jones, Jean-Marc Eber, Julian Seward. ICFP, 2000 http://www.lexifi.com/downloads/MLFiPaper.pdf
See also: http://homepages.inf.ed.ac.uk/wadler/realworld/lexifi.html
"... with Release 33-9117, the SEC is considering substitution of Python or another programming language for legal English as a basis for some of its regulations."
If this was actually implemented, it'd be incredible. No more ambiguity when you have to define all the parameters and outcomes explicitly!
To some extent financial transactions are done on the basis of code anyway.
It's not unusual for transactions to specify a price based upon an agreed software-as-a-service calculation, for example an agreement might say "we will purchase 10,000 shares, on the 12th of May at the price defined by Bloomberg VWAP (volume weighted average price)".
So rather than the parties having to draft a five page document defining exactly the criteria used to calculate VWAP (i.e. which trades to include and exclude) they just say "we'll use the criteria defined by this code".
This could open up a very lucrative market for Python experts.
I'd think a DSL would be better for this purpose (defining rules for a specific type of financial assest) than Python in general.
It's also worth noting that this is a minor part of a much larger proposal that came out more than a week ago. A bunch of media outlets ran stories... the NYT article is here:
previous discussion: http://news.ycombinator.com/item?id=1272541
This is definitely a strongly-typed-language situation.
Why not a framework which uses plain English like Cucumber? http://cukes.info
What if the rules are self-mutating bytecode?
I would think a DSL would be more appropriate than straight Python for the proposed purpose.
article title is wrong, this isn't Ruby.
should be: "Will Wall Street import Python?"
I don't know if I fully understand or agree with their proposal but I like the fact that they are trying to innovate.
I would only consider a language with built-in big rational numbers.
Quick explanation of what exactly this is:
It's a rule change regarding asset-backed securities. ABS are a type of bond where the interest and principal payments come from the cashflows of some pool of underlying assets. The simplest example is the now-infamous mortgage-backed security: a bunch of mortgages are put into a pool, and each month the homeowner's payments are passed through to the mortgage-backed securities holder (with some amount taken off the top to cover the cost of collecting, processing, and insuring payments).
There are many generalizations of this concept. There's no reason the underlying asset has to be mortgages. It could be auto loans, credit card receivables, student loans, whatever. And there's no reason that the cashflows have to be passed straight through to the bondholders. This is where Python comes in.
There are a number of complicated rules you can define. For example, let's suppose I have $100mm of assets. Rather than just having $100mm in bonds on the other side, I can define two pieces, or tranches. Tranche A is $80mm and gets paid first; the $20mm Tranche B gets paid next. So if some assets don't perform and the $100mm face value only turns out to yield $90mm, the investors in A are completely unaffected. This method is helpful because it can create a safe asset out of a pool of generally unsafe assets.
Another possible rule would be again to define two tranches, A and B. Each month, A and B receive the full interest payments on the $100mm assets. But A gets the first $50mm in principal, and B only starts getting paid principal when A is completely paid off. That way, tranche A has a shorter average life than the underlying pool of assets, and tranche B has a longer average life. This is helpful because some investors might want to buy short-term assets, but others might want to buy long-term assets.
You can define a hugely complex range of rules, depending on the purpose of the investment and the type of underlying asset. From what I can tell (I obviously haven't read the whole document), the SEC is proposing to require ABS issuers to specify these rules in Python, and to specify the underlying asset pool in an XML format. This will make it easier for independent investors to analyze the securities on their own, without having to let the now-discredited rating agencies do their work for them.
In general, sounds like a great rule to me.