[Ironpython-users] feedback on PEP 421

[Markus Schaber]

Hi, Jeff,

Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Mon, May 7, 2012 at 1:11 AM, Markus Schaber <m.schaber at 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.schaber at 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