回复内容：
多谢大家的回答，一些问题的交流就发在我的这个回答里了。
特别感谢何波、董可人、Mr Mistake、LIKE
首先，为什么用python ？
目前本人所在的公司一共有三款平台，分别基于C++， C#和python。其中C#和python平台都是由交易员开发；C++平台则是由专职IT团队作为一个通用平台开发，内部组件进行了封装（交易员不可见），对外提供行情、交易的API用于策略开发（除了C++ 外也包括C#和python可用的API）。
理论上这款C++平台应该是最为稳定和强大的，由专业人士设计，同时采用封装核心，暴露API，支持组件模块开发，linux服务器运行的形式。
但是在实际运用中，交易团队表达了一个强烈的观点：这个平台实在是太难用了！
1.
由IT团队设计的API功能非常强大，但是也太过繁琐，导致学习曲线极为陡峭
2.
为了追求速度，没有设计原生GUI（本来就为了在Linux服务器上跑），但是今天绝大多数的非超高频（追求微秒级延迟的那种）交易策略，几乎都需要有人实时监控，你总不能让交易员盯着个linux shell上不断print出来的内容或者盘中去翻日志吧，这个运维风险就扛不起。尽管可以作为插件的形式开发GUI，但C++本身的GUI开发还是较为复杂的，非专业IT很难搞的定。
3.
交易员团队的需求变化很快，通常等不及IT去排班开发，最好是今天收盘有个点子，明天开盘就能开始接实盘数据验证，没问题后天就能上实盘。比如去年四季度的分级基金套利机会就是稍纵即逝，那段时间如果能快速开发完成一套专门的监控套利系统，抓住的利润绝对会比用excel接wind数据来的多不少。
4.
某些业务逻辑确实太过复杂，交易员想解释让IT明白，无奈IT并不是太擅长某些金融领域（比如期权高频套利的整个业务框架），交流成本太高。
用web开发来做比较的话，C++实现的量化交易平台像是java在网络开发领域的地位，强大（几乎无所不能）、稳定（无数大公司的支持），但是也很臃肿（你一两个人开发试试）。
以上的原因促成了我坚持使用python开发一个交易平台，这款平台的定位好比于node.js为前端工程师（用户体验的直接缔造者）提供了一个简洁又不失强大的后端平台，主要的目标用户群是中小型量化团队（根据我的经验，绝大部分的券商自营、期货资管和基金量化部门都不大）、专业的交易员团队（可以雇得起少量专职IT）以及一部分打算从互联网领域转行来的程序猿们（python在互联网公司用的不少）。
总结下python在量化平台开发方面的优缺点（欢迎补充）。
优点：
1.
动态语言的快速开发特性，封接口有boost.python，写GUI有PyQt，时间序列有numpy，等等，几乎你想干的事都有现成的库可以用，这里吐槽下公司大牛自己写C++里的简单移动平均（SMA）算法，确实比常规实现快不少，但似乎对pnl没什么直接帮助。
2.
学习成本低，这点算是个共识了吧？
3.
真需要低延迟的时候，胶水语言很容易通过其他语言拓展：cython, ctypes, boost.python等等。
4.
运行速度足够快，也许和C++比起来确实慢了不少，但是就我的经验来看，这点速度延迟对90%的策略pnl毫无影响。
缺点：
1.
GIL，该死的全局锁导致python无法有效利用多核CPU的性能，尽管可以通过拓展绕过去，但还是没有其他语言原生多线程利用多核的方案来的简便。
2.
没有静态类型检查，重构的时候确实有点痛苦，不过一个良好的编程范式可以有效解决这个问题。
3.
不适合用来搞超高频策略（追求微秒级延迟的差异），得承认这点python确实搞不过C++。常规基于TICK级数据的策略没问题。
协议方面
打算设计的尽可能宽松一些，代码可以随便修改、使用、分发、做成商业产品拿出去卖，都免费。
交易亏钱了别来找我。
开源平台的内容
目前计划包括：
1.
一个C++ API的封装框架，国内绝大部分交易API都是C++的，手动写python封装非常繁琐（不难），github上有个pyctp项目尽管已经存在了很久，但人气不高，个人认为和代码复杂度有关（目前据说是使用cython自动生成，没有详细的使用说明）。初期将会封装一个华宝证券LTS的API，一来ETF期权上市我目前也在做，二来和CTP的API几乎通用，金仕达、恒生也都提供通用接口。
2.
一个事件驱动引擎，这东西不复杂，但是没见过的人第一次确实不好理解，身边大量朋友的经验。
3.
基于封装API，事件驱动引擎，PyQt的一个桌面交易程序，将会实现LTS柜台上的绝大部分功能。
4.
一个策略运行接口和策略模板，用于降低从金字塔、TB等软件上转移过来的用户的入门难度。
发布平台
打算用GitHub，不过今天刚看到海风的AT平台发布在了开源中国上，不知道有什么深意不？
关于Quantopian
这个确实是欧美在python量化交易领域的先行者，zipline库闻名已久，自己没用过。不过和我这个项目的方向略有不同，一来它接的是IB的API，二来它主要还是为自己的这个web应用服务（在服务器运行）。我的项目将会服务于中国用户，同时希望用户在自己的本地跑，不要受到第三方任何服务器的约束（谁都不想被偷策略）。
另外目前在quantopian上并没有看到过特别好的策略，也许好东西不会免费放出来，but who knows.
2015/2/26 更新
董可人的一些评论：
1.
这个平台的定位处于TB、MC之类的低端量化软件和大型量化团队自己开发的复杂量化平台（Java、C++）之间，目标就是快速上手、开放源代码可以随便改、真要性能不足了容易上拓展（cython等等）。
2.
Python缺乏静态检测确实是个不小的问题，比较容易出bug，解决方案是：
a)
平台采取非常简单的核心架构，用户容易掌握所有源代码细节
b)
测试，其实静态语言写出来的东西也还是得测试，python写测试还快些
3.
框架本身不包含图形界面，我写上去的一个界面属于简化示例。从python角度上，可以将底层逻辑和GUI分到两个进程中，然后跨进程通讯，但这个方案对于快速开发的需求来说麻烦了点，可以作为业务需求稳定后改进的方向（其实就是我偷懒想交给开源社区来开发，不过确实我自己目前没这块需求）.
4.
国内的交易API通常是C++的，网络数据收发在C++环境中完成。在API封装中我做了个队列作为缓冲区向python中推数据，防止由于C++ API的回调函数被阻塞导致程序崩溃（这个坑没自己遇到过很难想到会有）。GUI端的更新我在期权做市过程中大概是每秒更新上千个表格中的单元格同时同步刷新大概40多条波动率曲线，耗时也就是几十毫秒而已，要知道国内的数据量和欧美不在一个数量级，所以并不是特别大问题，当然也调整了算法和GUI在事件驱动中的运行顺序后保证算法的优先响应，。
5.
Esper那玩意太复杂了。我这个事件引擎就是实现不同组件向引擎注册对某个事件的监听，然后事件来了分发通知，懂编程的大神必然觉得是个小case，但对于大部分交易员而言这是个神奇的东西。
6.
Trader被逼写代码这种事在国内已经成为一个必然趋势了，光是期权做市和套利平台，目前上海这里大量的欧美海龟期权交易员在寻找解决方案，希望这个框架能降低一些进入门槛吧。
Mr Mistake的一些评论:
1.
目前我的整个平台（框架+业务模块）加起来已经上万行代码，设计方面使用了不少OO，确实偶尔我也希望python能报编译错误。。。
2.
用python的目标就是容易，真要性能我也直接去在公司那个C++平台上写得了。
3.
Python的GIL就是个大坑，希望目前dropbox那个pyston项目能成功。
4.
这种快速开发的工作通常是交易员自己负责的，策略不见得是那种长期运行的非常稳定的全自动策略，可能是某种需要程序辅助的半自动交易策略，比如同时监控市场上3000只股票的某些技术特征，然后盘中监控提示，辅助快速下单，用C++当然能写，但等写好估计交易员的需求已经变了。
5.
国内交易所只提供标准的通信协议，然后由各家柜台公司接入后，对外提供柜台交易接口，通常是C++，期望能试着推动改变这个情况（每个接口都要封也太累了）。
2015/3/2 更新
项目在Github的地址 vnpy/vnpy · GitHub
开发环境说明：
windows 7 专业版
visual studio 2013 express
boost 1.57.0
python环境Anaconda 1.9.2（32位）
刚完成了LTS API的封装和行情API的测试脚本，先上传了，接下来的工作顺序是：
1. 交易API测试脚本
2. 事件驱动引擎
3. API的封装方面的教程
4. 事件驱动引擎使用方面的教程
5. 基于API和引擎开发的LTS交易客户平台（因为华宝没有提供官方的LTS交易软件）
6. 策略引擎接口
2015/3/3 更新
完成了API的封装，上传了交易API的测试脚本。
目前玩过boost.python的大神可以通过vnltsmd和vnltstd目录下的C++源代码编译出API，每个目录下的test文件夹里包含了编译好的API，使用方法参见测试脚本。
争取明天放出事件驱动引擎后开始制作教程。
2015/3/3 二次更新
工作效率不错，已经放出了事件驱动引擎，有兴趣的可以看下了。
项目的主页发布在http:// vnpy.github.io
前ORC员工，挺支持题主的想法的，python去做量化交易的模型也是比较容易实现的。
Python如果进行快速prototype或者只进行编写最上层的策略本身而不进行order management，trade synchronization, 以及与您提到的与交易所或者broker进行的connectivity，那么还是非常不错的，有numpy, pandas等优秀的library。
不过对于一个专业的交易系统，尤其是量化平台难度很大，仅仅python也很难满足需求，需要多种技术的结合，没有一个专业的团队合作是很难完成的。主要的问题在于python这种动态语言，写时一时爽，重构哭天喊地了要。
大致说一下这么一套系统的难点：
交易系统本身的架构： 大量运算、order的执行与管理、对外的连接都需要服务器端的程序处理 CPU intensive的处理，放在服务器端会有非常明显的优势 服务器端会非常稳定，试想你的电脑出现windows更新等等 网络方面的代码需要服务器端至少交易时段和交易所亦或是券商连接，需要处理大吞吐、低延迟的网络编程。 交易、图形、报告界面需要GUI - 一般会运行在Windows或mac上（ORC最早的时候只有Mac版本的ORC Trader, 如果trader想要交易必须配置mac机器，想想也是醉了。。。），亦或是只用浏览器来控制交易，那么势必对后端的代码要求更加高。 由此可见你很难仅仅是一个“程序”就把一套交易系统给运作起来，这里就需要自己去设计一套基础的内部协议框架能让各个trading system的component去运作起来。给一个建议就是可以参考FIX，但这个协议也仅仅是偏向于order execution与基础的market data，比如risk方面的: Alpha, Beta, Sharpe就不要指望这种协议会帮你定义了。
做好了协议之后，那么问题又来了，这些component之间哪些需要低延迟哪些需要高吞吐，哪些需要TCP哪些用UDP就可以解决了。。
所以一般你会发现你需要做一个这样的交易系统：
GUI Client <---------> Gateway 1 <---------> HK Exchange / Broker
Strategy Execution Engine <-------> Gateway 2 <---------> Tokyo Exchange / Broker
Gateway会帮你做一部分order management和处理每个市场的微观不同，比如每个市场的order type也会有相当大的不同，但是如何让一个trading desk能有a view of whole portfolio(不同市场的orders， trades, portfolio returns, risks)，this is a hard problem.
兴许你就需要一套非常好的SOA - service oriented architecture来做分布式系统。
PS: 仅仅是一个gateway的编写就需要一个程序员对金融交易市场有很细致深入的了解，他的头脑里面就要有how the orders matched in this market. 这也就是你文中提到的基于“柜台API”的开发，要知道国外（包括HK，台湾）很多市场不会有“API” 给你的，只会有一个网络协议。
再后来，你会发现有更多的需求，比如满足风控，想有各种options pricing的计算，那么系统继续拓展：
Strategy Execution Engine <-----> Pre Risk <----> Gateway <------> Post Trade Risk <----> Exchange.
OMG！我如何track我的order flow呢？我的order到底到哪里挂掉了？是bug还是我的order不符合交易所的要求被reject了呢？到底在这个分布式系统中一个order的延迟多少？如果延迟过高的话我的策略会受到什么样的影响呢？
2. 功能
如果只是做click stock trading，兴许第一个架构就足够了。但是在金融领域会有很多细分的功能，如果是market making你会需要理解how quoting works, 但是click trading中只有order的concept兴许就够了。
如果是券商的系统，他们兴许还需要知道每个用户的order、position的情况来处理突发情况或者风控等。
如果是algo trading，兴许你还要提供科学计算的可能性。
题主提到希望直接使用柜台API来进行操作，那么还涉及到这样的交易是DMA(Direct Market Acccess)，券商未必会放开让你直接做DMA的在国内。那么又需要考虑连接哪家券商的API的问题。
所以综上，兴许从一个部分出发做开源会更好，focus在一个方向做好。
关于license，我们以前是从来绝对不会用GPL的，it's like a virus... 只能把代码自己写也不用GPL的。
现在我和另外一位前同事以及前投行交易组的朋友、BAT小伙伴做了
http://www. ricequant.com 。 也是想把量化交易更加开放地带给大家，我们拿着低延迟系统在做这么一个开放、免费的平台，也希望大家喜欢。
Happy Coding & Happy Trading.
谢邀~~
楼主的想法的确挺好，支持，谈几点我的看法吧。
1. 楼主为何选择python？是因为自己熟悉python还是？我觉得选择什么语言应该是根据系统的特点去选择，而不是根据自己擅长去选择。python作为交易系统的核心，低延迟很难达到要求。python作为胶水语言，在quants中广为流传，主要用于策略研发过程和数据分析，或者作为胶水黏合各个系统。直接用于交易系统本身还是比较少吧。
2. 关于协议方面，GPL还是LGPL完全基于作者你自己的意愿，你去了解了GPL和LGPL相关的约束就明白了，还能采用更宽松的BSD协议。
3. 对于开源整个交易平台本身，我倒觉得分成独立的模块更合适，前端行情的Quote Proxy，后端交易的Trade Proxy，不过这2个方面的确quantsBox已经做得不错了。然后对于中间的CEP引擎，策略引擎、订单管理、风控管理等模块作为一个个独立的项目来开发，然后约定好标准，这里标准的制定非常的重要，quote结构、order结构，message结构。这样对于做一个完整的交易系统，扩展性会好很多。
4. 发布平台选择GitHub就好，不过难说未来会不会被墙。。。
5. 社区就用github本身不就好了吗？
一看就是自己hands on不是闲扯淡的。平时直接接触python model所以来讨论一下。
1。弱类型语言对于小型系统的早期来说绝对快速。但是在代码上几千行以后，架构和重构基本就很痛苦了，需要很好的OO discipline 这就不是经验少的dev能做到的了。有时候你自己可能都希望python要是能报编译错误多好！
2。没看明白你的server side 和GUI是不是都要非得Python. 如果需要一个Server instance 加上n个GUI呢？在投行一般front end用WPF 多一些。后台不管Java c++ python都可以消息驱动的。用web也要但是很少。纯python的前台实话实说真的没见过。如果谁见过请告诉我，谢了。
3。现在性能对你来说可能不是问题，如果有一天需要高性能的时候numpy会有很大优势但是多线程不会像Java好用
4。像你提到的今天晚上有一idea明天就要进prod我看起来觉得有点吓人呢哈哈。迅速Agile release 是好事但是需要很强的dicipline : tests 写了多少 code coverage多少 CI有没有 deployment 是自动的不，每次有多少feature，Business test cases 写了没等等等等
5。python对交易所的接口API和性能怎么样？是不是直接被交易所首选支持的？
最后说一句吐槽的话，金融IT没看起来那么简单的需要很多积累。加油！
用python开发的现成平台quantopian都已经出hedge fund了吧。
这个平台是自建社区，然后通过平台上crowd-sourced 策略建立一个实盘基金，等于留住了很多人，并且保持住了后续开发的动力。
python实现对速度要求不高的策略应该是没问题的。
主要看你的定位在哪里。简单说，作为一个业余时间的练手就是很赞的作品，但要定位成专业交易平台则问题很多：
Python的问题不仅仅在于延迟性能，更致命的是这个弱类型语言很难做编译期静态检测，系统复杂以后很容易写出 bug。这对于交易系统这种对系统稳定性有苛刻要求的系统来说是很难接受的。 你的架构看起来是图形界面和策略代码都跑在一个进程里，如果这是真的那就意味着任何一个 UI 上的问题都有可能导致交易策略崩溃。看你的截图，开发这么复杂的图形界面要想不出问题，很难。 截图上还可以看出这个系统运行起来会同时跑很多个 Order。Order 多了以后首先是上面说的稳定性隐患很致命，你的系统一旦崩溃，那些还在运行的 Order 估计多半要手动清理了，手慢了可能会有直接损失。另外系统需要实时收发行情数据来更新界面，如果架构上没有解藕的话，很可能意味着界面更新慢会阻塞网络数据的收发（俗称 backpressure）。 事件驱动引擎要做好并不容易。比如有名的 Esper 基本上，从计算机系统的角度考虑，我觉得最好还是不要定位成一个大而全的一体化交易系统为好。你作为一个交易员，如果能把自己熟悉的业务部分的若干模块提炼出来做精就很有价值了。
开源协议 GPL 系是大忌，慎入。GPL 的意思是用了你的代码以后，自己的二次开发也要强制开源，这意味着所有的交易策略都要开源，那就没人敢用你的东西了。
如果有兴趣在系统开发上向前走，几点建议是：
核心策略相关的代码用强类型语言编写，做足检查和测试 至少在进程粒度上把图形界面和交易策略分开 现在的图形界面是 Web 的天下了，试着学学 HTML/CSS/Javascript。 看到题主的回答中这一段非常有感触：
但是在实际运用中，交易团队表达了一个强烈的观点：这个平台实在是太难用了！
1. 由IT团队设计的API功能非常强大，但是也太过繁琐，导致学习曲线极为陡峭
2. 为了追求速度，没有设计原生GUI（本来就为了在Linux服务器上跑），但是今天绝大多数的非超高频（追求微秒级延迟的那种）交易策略，几乎都需要有人实时监控，你总不能让交易员盯着个linux shell上不断print出来的内容或者盘中去翻日志吧，这个运维风险就扛不起。尽管可以作为插件的形式开发GUI，但C++本身的GUI开发还是较为复杂的，非专业IT很难搞的定。
3. 交易员团队的需求变化很快，通常等不及IT去排班开发，最好是今天收盘有个点子，明天开盘就能开始接实盘数据验证，没问题后天就能上实盘。比如去年四季度的分级基金套利机会就是稍纵即逝，那段时间如果能快速开发完成一套专门的监控套利系统，抓住的利润绝对会比用excel接wind数据来的多不少。
4. 某些业务逻辑确实太过复杂，交易员想解释让IT明白，无奈IT并不是太擅长某些金融领域（比如期权高频套利的整个业务框架），交流成本太高。
这可以说是纯 IT 背景的人入行会遭遇的最大的挑战，一个 Pure IT Role 其实是很难适应交易这个行业的。干这行是非常需要复合型人才的，IT 如果只满足于在自己一亩三分地恪守软件开发的职责，后果就是 Trader 们被逼自己写代码，这实在是一出悲剧。
赞一个。python看过没上手，但感觉很亲切。
关于开源AT到oschina，没啥深意，用了一下感觉好用就挪地儿了^_^
系统架构都是共通的，语言选择上，一是个人熟悉（毕竟熟悉的东西解决问题更容易）二是够用（追求完美是iter天性，同时也是个坑）^_^
基于python的平台就应该是主要面向个人和小型机构投资者了吧，建议做好恒生和ctp的接口就应该很有市场了，如果有余力把金证的做了更好
先赞。不过如果不开放业务细节的话，就是简单的行情模块、订单模块、波动率模块、风控模块的交互。核心就在波动率定价，再者就是根据波动率的报价逻辑。。这个不开源，其他意义不大，就是通讯和界面。
好多回答片面甚至谬误的观念实在不能忍，回答一下。
• 延迟高低？交易系统的网络延迟绝对比语言层面高一个数量级。比如大券商，选低延迟的系统，完全没有选机房重要。著名的外高桥机房，报价会吓死网络公司，但是券商却很多。
• 高频量大？你需要的是分布式设计，多个消费端加个消息队列是基本。
• 工程化？ 可读性，重构，包管理，设计模式。。。所有这些都是工程化思想。所有开发人员其实都应该学学php再去学学laravel这个开发框架。可以深刻理解到，作为工程化思想几乎为0，被嘲讽了这么多年的php，在合格的开发手里，是怎么做到工程化其实完全不比java差。
• 线程优化性能？ 现在流行的都是进程+协程的方式了，几乎所有主流语言都能轻松实现。python的GIL在这个方式下就完全无关了。python的发明人，大神Guido也解释过为什么设计GIL，这个设计只能说有优点也有缺点（对初级开发来说，优点还重要点），没有说移除了GIL的实现就强大很多，不然大神最初就不用加上GIL了。
• 测试？ 静态检查只是最最最基础的测试。单元测试没有全覆盖，没有自动化测试，怪语言容易出bug？这什么逻辑。。。python有behave和lettuce，php有behat，ruby有cucumber，测试界早已经进化出行为测试，但是按照我的面试结果看，这些测试框架，90%的开发人员完全没使用过，甚至都没听说过。这是怪人还是怪语言？你们吐槽的脚本语言没有静态检查，实际是——人家根本不需要。
• GUI？ 自从有了nodejs，html5+css3+js才是开发GUI利器（又有很多传统开发完全没听过）。开发速度完胜，性能完全没有问题。可以参见github开源编辑器atom的实现。当然python用pyQt来开发GUI也完全没有问题。
• 事件驱动？ 这是python的强项好不好。。。
综合题主的需求，用python开发完全是完美选择。
技术开发需要永远保持旺盛的好奇心，不断学习新技术和概念，才能保持跟上这个不断飞速进化和发展的体系。很辛苦，但是很值得。
