OK, that sounds like a reasonable way to do it. Very nice that it is automatically verifiable!
But it opens more questions from me, sorry. I find this interesting :) So when an automatic test, that is determined to be a implementation detail, fails - how does IronPython "skip" it? Is the actual test suite specific for IronPython? I mean, is the unit tests in IronPython a fork of CPythons test suite? Anyone know how many per cent of the CPython test suite that IronPython pass? On 11 April 2014 10:52, Vernon D. Cole <vernondc...@gmail.com> wrote: > Compliance is determined by running the same test suite as CPython (the > reference implementation). The only tricky part is, should a test fail, > determining whether it is testing a language feature (must fix) or an > implementation detail (can skip). > For example, tests involving the Garbage Collector or GIL would be > skipped, because IronPython does not use them. > > > On Fri, Apr 11, 2014 at 1:50 AM, Olof Bjarnason <olof.bjarna...@gmail.com> > wrote: >> >> To just add my relative outsider opinion (new user of IronPython, 5+ >> year user of CPython). >> >> As long as a IronPython version does not adhere 100% to a CPython >> version, it does not make sense to follow same version name >> convention. >> >> Better then to have a completely different "scale", e.g. 0.xyz. In >> fact, as long as IronPython doesn't adhere to CPython <some version>, >> does it even make sense to have a version beyond 1.0? >> >> On the topic of Python compliance, how do you determine exactly how >> compliant IronPython is? How does PyPy determine this? >> >> On 10 April 2014 11:39, Jeff Hardy <jdha...@gmail.com> wrote: >> > On Thu, Apr 10, 2014 at 10:05 AM, Vernon D. Cole <vernondc...@gmail.com> >> > wrote: >> >> Jeff Hardy stated:.. >> >>> >> >>> In addition, 3.0 will include most (but perhaps not all!) of 3.4's >> >>> features, mainly because I'd like to see a release later this year >> >>> (around October) and things like nonlocal or importlib could slip >> >>> because they're hard and not terribly exciting. Calling a release like >> >>> that 3.4 is a problem because it's really not 3.4-compatible. >> >>> >> >> True, but calling it 3.3 would not be a problem, I think. >> > >> > But it wouldn't be 3.3 either, since nonlocal was added in 3.0. (And >> > I'm not saying we won't get to nonlocal, it's just an example). >> > IronPython 3 likely isn't going to line up with any CPython 3 release >> > feature-wise at first. >> > >> >> >> >>> >> >>> Once the Python 3 features are in place, I want to make it as >> >>> cross-platform as possible - iOS, Android, Windows 8, etc. That would >> >>> strongly imply a new version number since it will require a new DLR >> >>> version to be used (not very good to slip a DLR version change into a >> >>> 3.4.z release). Hence I'd prefer to keep the ability to call it 3.1 >> >>> (or whatever) instead. >> >> >> >> >> >> Well, speaking of cross-platform, most of my work in the near future >> >> will >> >> probably be on Mono -- so different DLRs will be kind of a normal >> >> thing. I >> >> don't have a problem with that being a factor in a point-level release >> >> -- it >> >> is an implementation detail, not a language change. >> > >> > It's an issue if there are multiple languages depending on the same >> > DLR version, which was one of the promises of the DLR. Now, I'm not >> > sure anyone *uses* that ability, but I don't want to casually throw it >> > away, either. >> > >> > I think there's an expectation that in an x.y.z scheme, z releases >> > should not make major changes. If IronPython's x.y is fixed to >> > CPython's, then our ability to make major changes is tied to CPython's >> > ~18 month release schedule. At least for the next few releases I'd >> > like the flexibility to increase version numbers in accordance with >> > expected norms (i.e. as close to semver as we can manage), but if/when >> > we catch up then maybe it makes sense to synchronize. >> > >> > - Jeff >> > _______________________________________________ >> > Ironpython-users mailing list >> > Ironpython-users@python.org >> > https://mail.python.org/mailman/listinfo/ironpython-users > > _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
