I got such excellent help from Python-dev on the Prothon decimal question that I've come back for a really big question. :-) I've announced recently that Prothon was switching from a homegrown (CProthon) interpreter to a .Net implementation like IronPython. The logic was that Prothon would get a library and a community much faster. What it got very quickly was a backlash from people, including Guido, who wanted Prothon to stay away from the dark side and remain pure like CPython. I've said in the past that Prothon couldn't use the CPython interpreter. I made this determination late last year when I first started the Prothon project because CPython was incompatible with my goals of pre-emptive threads with no GIL, object locking, etc. Now I find myself compromising my goals for .Net in that I cannot implement object-locking and lightweight threads. I am also going to be mixing real classes with my prototypes, although this is something I have determined I want to do for other reasons (it's a long story). I'm sure you've heard the joke that ends with "we've established you're a whore, now we are just haggling over the price". If I can compromise Prothon for .Net, why can't I compromise it some more for CPython? So I am thinking of doing a Prothon implementation in CPython before doing the .Net version. I will get a library and community fast like I would have with .Net. This CPython->.Net->CProthon roadmap will get Prothon out quickly and slowly easy my wild ideas for the interpreter into Prothon. It will also make CPython a multiple language VM for the first time. So, I'll finally get to some questions: 1) Guido: Does this address the reason you asked me not to switch to .Net, or did you specifically want me to do CProthon? I think this will still be a good sandbox for Python. It should be quite interesting to see how far I can stretch the Python interpreter. Who knows how many of my CProthon engine features I might be able to add to CPython. 2) Lenard Lindstrom said he thought I could "Add some extra byte code instructions to handle Prothon's distinct scoping rules and implement prototypes using PyType_Type". He also said "All attribute accesses would be through a special attribute handler method". I don't know the Python interpreter code yet, but does this sound workable to everyone? It doesn't have to be Python compatible. 3) Could Tim Peter's welcome offer to Prothon here on Python-dev be stretched to include the many questions I would have when modifying CPython? In other words would this project be welcomed as a sandbox for Python or would it be an unwelcome drain on your limited resources? If any of you want to see background material on Prothon, my VanPy talk is at: http://prothon.org/pub/prothon/docs/vanpy/ProthonTalk.htm. The section titled "engine" is about the homegrown engine and wouldn't be applicable to anything on .Net or CPython. Thanks for you attention. I would love to find a solution that lets me work with the wonderful Python community.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4