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
> PyClass PyClass - 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
