Re: [pirate] Python PMC's
Kevin Tew wrote: Problem: Python PMC's just don't work in the leo-cxt5 branch which will become head/trunk at some time in the hopefully not to distant future. What I've done up time now: I've ported pyint.pmc, pystring.pmc to pass all tests in leo-cxt5 I've written t/dynclasses/pystring.t Note that there are something like 15-20 python.pmc's or which only 4 have corresponding test in I've written t/dynclasses/ I've ripped out a lot of the explicit passing of self as the first argument of pmc methods. - We don't have to pass self around, parrot makes it available to us automatically. I added self on Leo's request. Now it is unneccessary. *shrug* Sam's implementation of Python PMC is old and outdated. He did a lot of pioneering work in the realm of the python object system on parrot. Probably the first real attempt at a full object system on top of parrot. Parrot has changed drastically since then. Sam's PMC's were also incomplete, they lacked support for a lot of the __add__ style python methods. This is quite understandable, Sam was trying to get something working. Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were working, and tested. Proposal: I propose to gut all of PyObject, PyFunc, PyClass, PyType PMC's etc. Old New PyObject PyObject - will represent a instantiation of a python class, will inherit from ParrotObject PyClassPyClass - will represent a python class, will inherit from ParrotClass PyType PyMetaClass - will represent the meta-class of a class, this one is still open for debate. I plan on making these changes via test driven development. The plan is to reduce python object system pmc's code content and functionality to zero, and then rebuild it up Mainly because every time I try to morph Sam's code, Leo tells me the whole approach is wrong :) We will rebuild the python object system based on test cases, If functionality is missing, and you want it implemented, write and submit a test case first. 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 $* 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. 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. Kevin Tew ___ pirate mailing list [EMAIL PROTECTED] http://cornerhost.com/mailman/listinfo/pirate - Sam Ruby
Re: [pirate] Python PMC's
On Aug 23, 2005, at 17:09, Kevin Tew wrote: Problem: Python PMC's just don't work in the leo-cxt5 branch which will become head/trunk at some time in the hopefully not to distant future. Err, I hope to merge RSN ;-) 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. This isn't quite right - or only partially I think. The main problem with properties is: props dont' inherit. It of course depends a lot on the Pyton - PIR translator. But I think the following strategy should work: - use parrot object system with a PyClass base class - make the compiler smarter about attribute access, it can create a list of attribute names - let these static attributes be handled by the parrot code - provide an additional hash slot (__dict__) as another internal attribute for dynamic attributes and per object attributes - Python __slots__ translates to the arrayish Parrot layout w/o changes probably - you have to check for __xxx__ attributes anyway to get e.g. overloading or other special attribute handling done correctly. Comments welcome. Kevin Tew leo
Re: [pirate] Python PMC's
On Tue, Aug 23, 2005 at 12:21:42PM -0400, Sam Ruby wrote: Kevin Tew wrote: I've ripped out a lot of the explicit passing of self as the first argument of pmc methods. - We don't have to pass self around, parrot makes it available to us automatically. I added self on Leo's request. Now it is unneccessary. *shrug* Parrot's calling conventions having updated, everybody must adjust, it's not about Pirate. I like to think that this most recent change in calling convention is an improvement, by and large. Sam's implementation of Python PMC is old and outdated. He did a lot of pioneering work in the realm of the python object system on parrot. Probably the first real attempt at a full object system on top of parrot. Parrot has changed drastically since then. Sam's PMC's were also incomplete, they lacked support for a lot of the __add__ style python methods. This is quite understandable, Sam was trying to get something working. Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were working, and tested. I remember seeing the implementation of __*__. It looked fine to me in design, though I didn't review every particular one. At OSCON I learned that IronPython contrives to make CLR classes look just like native Python classes even under introspection, and that's just plain nifty. The Parrot equivalent would be to make the class look like it has an __add__ method iff the underlying Parrot class implements __add. Interesting? The plan is to reduce python object system pmc's code content and functionality to zero, and then rebuild it up Mainly because every time I try to morph Sam's code, Leo tells me the whole approach is wrong :) No matter what you do, Leo will tell you that the whole approach is wrong. It's a fair cop. Leo's always has strong ideas about how things should evolve. But in language-specific code like the Python classes, I don't see why Leo -- or I, for that matter -- should have standing to tell you what to do. If Python users are happy with the results, whatever they may be, and if the core functionality of Parrot isn't impacted for other languages, more power to you. If we got all unreasonable on you, you'd just take Pirate development out of the Parrot tree or else just quit, and neither of those alternatives is good for Parrot. As Larry says: Live and let learn. Therefore, if you _want_ to rebuild from zero, please by all means go ahead. Just be prepared to discover that the original structure was actually better than you thought. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [pirate] Python PMC's
On Tue, Aug 23, 2005 at 06:35:39PM +0200, Leopold Toetsch wrote: On Aug 23, 2005, at 17:09, Kevin Tew wrote: Problem: Python PMC's just don't work in the leo-cxt5 branch which will become head/trunk at some time in the hopefully not to distant future. Err, I hope to merge RSN ;-) That's my Parrot priority this week: the leo-ctx5 branch. I know I like the feature set, and it's just a matter of reviewing the interface and implementation details. And, since the collective You are reading this message, which therefore must exist, it can be deduced that I have more Parrot bandwidth this week than I have for the past $TIMEPERIOD. :-) -- Chip Salzenberg [EMAIL PROTECTED]
Re: [pirate] Python PMC's
On Aug 23, 2005, at 18:21, Sam Ruby wrote:
Kevin Tew wrote:
We don't have to pass self around, parrot
makes it available to us automatically.
I added self on Leo's request. Now it is unneccessary. *shrug*
Parrot's new calling conventions are passing 'self' as the first
argument of a method. Therefore all the old workarounds like:
METHOD PMC* __abs__(Interp* interp, PMC* SELF, PMC* self) {}
aren't needed any more.
Sam's PMC's were also incomplete, they lacked support for a lot of the
__add__ style python methods. This is quite understandable, Sam was
trying to get something working.
Check out parrot/t/dynclass/pyint_2.pmc. __add__ style methods were
working, and tested.
PMC* __add__(PMC *self, PMC *value)
Please note that this signature includes like above already the
interpreter and, SELF i.e. the invocant PMC. This is for sure not
correct. The implementation is in pyobject.pmc and redispatches via MMD
to the actual multi sub.
So yes, the pyint.t test worked - overloading didn't.
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!)
One year ago we had some discussion, where e.g. we both stated that the
object should be passed as first argument to methods. Now it's
eventually done in my branch.
I do agree with test-driven development. That is exactly the approach
I
took.
Well, I agree - until I see such tests (pyint_1):
$P2 = $P1.__abs__($P1)
- Sam Ruby
leo
Re: [pirate] Python PMC's
Leopold Toetsch wrote: I do agree with test-driven development. That is exactly the approach I took. Well, I agree - until I see such tests (pyint_1): $P2 = $P1.__abs__($P1) Take a look at the difference between r7254 and r7312. The tests originally passed without a self argument. Then I was told that that was all wrong, so I changed it (both the test and the code). Now Kevin is being told that passing self is all wrong. Reverting that particular change is not all that difficult. And it can be done without gutting. - Sam Ruby
Re: [pirate] Python PMC's
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.
Re: [pirate] Python PMC's Missed attachment
My current work. Python PMC Patch to leo5-cxt5
Re: [pirate] Python PMC's
Kevin Tew wrote: 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. Take a look at the following: Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type help, copyright, credits or license for more information. def f(a,b=1,c=2): ... pass ... f.func_defaults (1, 2) In December, this was fully implemented and tested. In pirate.py, search for self.append(setprop %s, 'func_defaults', %s % (ref, defaults)) and search for func_defaults in pyfunc.pmc, pyboundcall.pmc, and pybuiltin.pmc. Finally, take a look at the third test in parrot/languages/python/t/basic/func.t - Sam Ruby
Re: [pirate] Python PMC's
On Aug 23, 2005, at 20:28, Sam Ruby wrote: Leopold Toetsch wrote: I do agree with test-driven development. That is exactly the approach I took. Well, I agree - until I see such tests (pyint_1): $P2 = $P1.__abs__($P1) Take a look at the difference between r7254 and r7312. I just find a log message about the change w/o any reason. I have always proposed (against Dan's opinion) the the object should be passed as the first argument to methods. This is done now. I've stated that the old MMD syntax, which needed to pass the existing destination PMC is inappropriate, suboptimal and whatever for almost all HLLs. Now you have a complete opcode subset that returns *new* destination PMCs. http://xrl.us/g9dp .pragma n_operators 1 ... $P0 = $P1 + $P2 # return new $P0 PMC Here is a test I've written for pycomplex: .pragma n_operators 1 .HLL Python, python_group .sub main @MAIN .local pmc d, c c = new .PyComplex c = 3+4j d = abs c print d print \n $S0 = typeof d print $S0 print \n .end And *yes* that creates a new PyFloat. Please also not that python_group is autoloaded. Sam, please follow Parrot dev (or stop spreading FUD) - thanks. The tests originally passed without a self argument. Then I was told that that was all wrong, so I changed it (both the test and the code). Please show me one message where you was told that abs has a signature of that one in the test or that another 'self' should be passed in. - Sam Ruby leo
Re: [pirate] Python PMC's
On Tue, Aug 23, 2005 at 09:58:21PM +0200, Leopold Toetsch wrote: Sam, please follow Parrot dev (or stop spreading FUD) - thanks. Be gentle, please. Parrot needs language developers. I'm not saying you're right or wrong. I'm just asking you to be a little more diplomatic. -- Chip Salzenberg [EMAIL PROTECTED]
