Prothon is switching to the .NET platform

[John Roth]

"Mark Hahn" <mark at prothon.org> wrote in message
news:1dske12sbt1mj$.1aq70xrpy0r0i.dlg at 40tude.net...
> On Sat, 7 Aug 2004 07:01:55 -0400, John Roth wrote:
>
> > "Peter Otten" <__peter__ at web.de> wrote in message
> > news:cf1t0h$ond$03$1 at news.t-online.com...
> >> John Roth wrote:
> >>
> >>>
> >>> "Christopher T King" <squirrel at WPI.EDU> wrote in message
> >>> news:Pine.LNX.4.44.0408061533250.25906-100000 at ccc8.wpi.edu...
> >>>> On Fri, 6 Aug 2004, John Roth wrote:
> >>>>
> >>>> > I think it's possible to do prototypes within Python by
> >>>> > overriding the __getattribute__() magic method. It still
> >>>> > wouldn't be very pretty, but it should be able to do
> >>>> > everything except override the magic methods (those
> >>>> > seem to have to be in the class object for new style
> >>>> > classes).
> >>>>
> > [snip]
> >>>
> >>> What I was thinking of was more along the lines of:
> >>>
> >>> class ProtoBaseClass(object):
> >>>     def __getattribute__(self, attr):
> >>>         # call object.__getattribute__(self, __dict__)
> >>>         # find requested attribute
> >>
> >> Wouldn't that part be implied if you used __getattr__() instead of
> >> __getattribute()?
> >>
> >>>         # if not found, loop through back pointer chain
> >>>         # if it's not a function, return the attribute
> >>>         # if it is a function, wrap it in a method object and return
it.
> >>
> >> This means that an object sees all changes in its prototypes until
> >> explicitly assigned an attribute. Is this intentional? (real question,
I'm
> >> not familiar with prototyped languages)
> >
> > Actually, __getattribute__ sees all attribute requests, __getattr__
> > only sees requests where the attribute isn't found. The reason for
> > using __getattribute__ is that there are (I think) serious problems
> > with attempting to execute functions that weren't originally defined
> > in the base class or a subclass of the base class. In other words,
> > if the result is a function, there's more work that needs to be done,
> > and __getattr__ doesn't allow a hook to do it on the way out.
> >
> > The attempt from 2000 I referred to attempted to get around this
> > by using a callable instance together with a lambda. Unfortunately,
> > it didn't work when I tried it, and as I said, after looking at the
> > code I don't think it ever worked. The workaround for the function
> > problem might work, though.
>
> Lenard Lindstrom <len-l at telus.net> wrote a prototype implementation in
> Python.  He hangs out on the Prothon mailing list (and here also, I
> assume).  He probably knows more about this topic than anyone.

I'll have to check out what he's done - is it availible anywhere
other than by e-mail?

Hans Nowak just sent me a private e-mail pointing out that he
had done a Self-style implementation about a year ago. It looks
interesting, especially since it uses getattr and setattr rather than
getattribute. The trick with functions seems to be to use
new.instancemethod. Otherwise the code looks to be very
straightforward. __setattr__ just makes a couple of type
checks, insures that instances ending in _p are from the
selfish class, wraps functions in new.instancemethod and
rewraps methods likewise. __getattr__ implements the
inheritance rules.

The examples on his weblog (look at 2003-09-13) are quite nice;
he's got the clumsiness with instance methods down to one line after
the method, which seems to be a practical minimum. It should work
with the new decorator syntax as well.

John Roth
>
> Mark Hahn
> Prothon Author