Sam, Thanks for the comments, They were very much appreciated. Sam Ruby wrote: >I added self on Leo's request. Now it is unneccessary. *shrug* > I understand completely. >Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were >working, and tested. > Yes many are working, I should clarify, there are more to be added. >No matter what you do, Leo will tell you that the whole approach is >wrong. I talked this past weekend with Larry Wall, Chip Saltzberg, and >chromatic. Hopefully we will get some more people involved. Leo is >great at details, but has a tendency to set a new direction every week. > I say that knowing that Leo follows this list. (Hi Leo!) > >I do agree with test-driven development. That is exactly the approach I >took. I will also state that I learned a lot *ABOUT* *PYTHON* in >running the pie-thon tests. I'd recommend that you don't gut until you >try the following: > > * PirateTest.py is a good sanity test to say that you have something > resembling python to work with. Until that test passes, there isn't > much point. > > * parrot/t/dynclasses give you a similar level of confidence in the > pmcs. > > * Once you get that far, cd to parrot/languages/python and issue > "make". That will run the various tests (culiminating in the > pie-thon tests themselves). To run that test, you will need a small > batch file in your search PATH named "pirate". Mine looks like: > > export LD_LIBRARY_PATH=/home/rubys/runtime/parrot/dynext > python /home/rubys/pirate/pirate.py $* > > Point well taken, I've been leaning back between, rewrite and evolving your work. I have a current change set that is passing most of your original tests that are in t/dynclasses/py*.t It is more of an evolution than a rewrite, which I favor. Some test fail due to remaining uunimplemented features in leo-cxt5(default args), or my lack of understanding. But a lot of the tests pass.
I wrote the original email, mainly because I didn't agree with all of leo's comment. I do however value his insight and like to hear his ideas. I have learned what I know about parrot in many cases due to pestering Leo with questions. Leo++. Without Leo, I'd still probably be more lost than I am now. That being said I will continue with the evolution path rather than a gut and rewrite. >>One last design note. >>I had a conversation a long time ago with Dan, in which he agreed that >>given Python's property bag style object system. That class methods and >>data members should be stored in parrot properties and the vtable >>getattribute/setattribute methods for python pmcs should be overridden to >>use parrot properties instead parrot attributes. >>Sam's PMC appeared to follow the same idea though not fully flushed out, >>and I plan on building the new Python PMC in the same manner. >> > >It just might be more fully flushed out than you appreciate. > > Your completely right. My apologies. Bad last sentence of the paragraph on my part. I was trying to get some explanation and/or debate on attributes vs properties, which Leo seems to have done in his reply. >>Comments welcome. >> > >I'm following this list, and questions are welcome in return. Again, my >suggestion is to try to get the existing tests to work again - modifying >the tests as necessary to remove now unnecessary self parameters. And, >again, resist the temptation to follow Leo's advice du jour. Focus on >what is actually implemented - while that does change over time, running >code has a tendency to change more slowly than the advice you may receive. > Will do, attached is my work in progress for those interested. Comments appreciated and welcome.
