On Mon, Jan 20, 2014 at 10:13 AM, Markus Schaber <m.scha...@codesys.com> wrote: > Hi, Jeff, > > Good work, I'm all in favour of it. Splitting DLR, IronPython and IronRuby > into different projects is a good thing. > > Just some unordered thoughts: > > The python standard library could be fetched by the build script directly > from the cPython servers (maybe with a few local patches applied until those > are included upstream). The same may apply to other dependencies.
One of my stumbling blocks has been the best way to do this. Ideally I could bring in new versions using a 3-way merge to make it easier to deal with patches not available upstream. > > For the first IronPython 3 release, I suggest that you try to target Python > 3.4 directly, and skip the intermediate 3.0-3.3 releases. Yeah, that's the plan. Targeting 3.0 would be hard because IP already has the "native" _io module introduced in 3.1. :) This is also an opportunity to break the correspondence between CPython and IronPython version numbers, with the caveat that IronPython will never have a version number higher than CPython. > > Also, I think now it's time to hard-code .NET 4 as dependency and drop .NET > 2/3 - this will allow us to lots of #ifdefs and some other nasty code. Also, > the PAL concept may be extended to replace some of those #ifdefs (as already > mentioned on http://blog.jdhardy.ca/2013/06/ironpython-3-todo.html). In my > eyes, the main benefit of this will be that we (hopefully) can get rid of the > conditional project references (which are a little PITA because they are not > handled well by Visual Studio). The new projects handle conditional refs a bit differently, and Visual Studio gets much less confused. Extending the PAL is probably the biggest architectural change I want to make (in a perfect world IronPython.dll would be a PCL, but I don't know if that's possible), but major refactorings there are less time spent on implementing Python 3 features (and there are only so many hours in a day, sadly). Right now I think 3.0 should focus on Python 3 features and 3.1 should focus on better platform support. Python 3 evolves very slowly, so once we get caught up, there'll be more time to work on other stuff. > > For debugging purposes, it may still be handy to have a combined .sln which > contains IronPython, DLR and maybe the hosting application, but it should be > possible to retain the capability to create such a solution. Yeah, I've had to do that a few times, so it will wtill be possible if not supplied. If I can get symbolsource.org integrated with the NuGet packages it might reduce the need to do that. - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
