Hi, Jeff, Von: Jeff Hardy [mailto:jdha...@gmail.com] > On Mon, May 7, 2012 at 1:11 AM, Markus Schaber <m.scha...@3s-software.com> > wrote: > > Hmm, maybe we could put the host/embedder info I suggested in the other > mail there. > > Yeah, and things like which which CLR version (3.5, 4.0), implementation > (MS, Mono), subset (Silverlight, MonoTouch, MonoDroid), what host it's > running under, etc. I was thinking of adding fields to clr for that > information anyway, but it can go here instead.
Sounds good. Everything of that informational stuff is far better placed there than in clr. If only for the fact that it can be probed without "import clr" which comes with some side effects. > >> I'm not really sure there's much value in having sys.version_info and > >> sys.implementation.version be different, but I believe PyPy works > >> that way, so I have no objection to it. They'll be the same in > >> IronPython, though. > > > > Hmm. It would open the possibility of IronPython supporting both Python > 2.7 and 3.X for some grace period... > > That ... yikes. It already does support some (not much) stuff using - > X:Python30, but that introduces a bunch of if statements and makes the > code quite messy. There are other ways to do it, but a clean break in a > new branch seems preferable to me. I agree here, it is much easier and cleaner to develop in two different branches. > Plus there's the issue of the > reorganized stdlib, which I'm not really sure how to cleanly solve. For the python part, it is easy: Deliver both versions in different directories, and set sys.path accordingly. For the C# part, maybe something like [PythonBindingAttribute(2)] and [PythonBindingAttribute(3)] could help. > So my > preference is to work in a different branch to 3k support. I'd like to do > some work after 2.7.3 is released, but I'm not sure I'll get to it. >From my own experience, it is the right way to branch, but often, when >everything is finished and cleaned up, one finds a realtively easy way to >reintegrate both branches. After all, Python 2 and Python 3 are not two >completely different languages (and IronPython2 already comes with some >Python3isms.). Don't get me wrong: right now, you should not try to force a generic implementation, but at least we should keep in mind that we can reevaluate everything once IronPython 3 is finished. Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
