On 18222 - I think ctypes will drive some changes to our buffer support making it more real. Right now it's close to useless :) There is some way for us to make types marshalable via COM ourselves so I think we'll be able to fix it eventually. I'm surprised that it's more of a problem than 18223 though.
> -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Vernon Cole > Sent: Wednesday, April 29, 2009 7:34 AM > To: Discussion of IronPython > Subject: Re: [IronPython] pywin32 on Iron Python? > > On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy <jdha...@gmail.com> wrote: > > Hi Dave, > > > > On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate <dfug...@microsoft.com> > wrote: > >> That said, there is something extremely useful the community can do > for IronPython that our team simply cannot: get 3rd party Python > applications such as Django, pywin32, NumPy, etc running under > IronPython. This could mean adapting something like adodbapi.py to > utilize IronPython APIs similar to what Vernon Cole did, or re- > implementing NumPy's C-based modules in C#. While it's quite difficult > (impossible?) for anyone on our team to submit changes supporting > IronPython back to other OSS projects, the rest of the IronPython > Community happily doesn't have this limitation. > > > Dave: > My condolences on having to put up with the lawyers. I have to sleep > with one, but at least she doesn't tell me who I can contribute code > to. ;-) > -- VC > > > The problem with this approach is that I don't really want to clutter > > up e.g. Django with workarounds for IP bugs that are actually > > incompatibilities with CPython - they should and will get fixed in IP > > at some point. If it's a legitimate platform difference, or an > invalid > > assumption by Django, then it can be fixed there - but I've found > very > > few of those relative to bugs in IP itself. > > That's true. There is still one outstanding bug in adodbapi on iron > which I hope will eventually be fixed in IPy. (see Work Item # 18222 > -- August 2008) The workaround was just too large to use and would > still have left the IPy COM implementation with a bug. When the COM > bug gets fixed that last test failure will go away. There are other > places where "if IronPython:" made sense and was used. (I also > included simple workarounds for bugs like #18223.) > -- VC > > > Also, would it possible for you guys to revisit your commit messages? > > I would at least like to see a note in the CP commit messages when a > > particular CP issue has been fixed. > > + 1. Maybe my bug has already been fixed and I don't know. > -- VC > > > > >> > >> If anyone wants to contribute in this manner, please just give us a > heads up so we can obtain permission to add tests for the 3rd party > app(s) to our checkin system. Also, if there's enough interest in this > I can setup a wiki page on CodePlex to keep track of whose working on > what... > > +1 on the wiki page. > > > > Now this is interesting! Last time I checked, Django's test suite was > > nowhere near passing - would the full test suite have to pass before > > you'd include it? > > In other words, how good do we have to get? > > > I really appreciate the work you guys are doing here. It can't be > easy > > swimming against the tide all the time! > > > > - Jeff > Amen! > -- VC > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
