This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Carl.Friedrich.Bolz, arigo, benjamin.peterson, brett.cannon, ncoghlan
Date 2008-10-30.22:32:38
SpamBayes Score 1.3422936e-08
Marked as misclassified No
Message-id <1225406020.38.0.596099804876.issue4242@psf.upfronthosting.co.za>
In-reply-to
Content
I personally wonder if we should be moving towards a more systematic
means of identifying the underlying Python VM than the current fairly ad
hoc use of sys.platform.

By that I mean adding another sys attribute (e.g. sys.vm) which could be
checked explicitly for the Python VM identity, rather than the
underlying platform.

E.g.

CPython: sys.vm == "cpython"
Jython:  sys.vm == "jython"
PyPy:  sys.vm == "pypy"
IronPython:  sys.vm == "ironpython"

Then instead of relying on a separate flag in test_support the
impl_detail decorator could be written based on the VM names:

def impl_detail(*vm_names):
  if not vm_names:
    vm_names = "cpython",
  if sys.vm in vm_names:
    # Test the implementation detail
  else:
    # Skip this test

Depending on how ambitious an implementer of an alternative VM wants to
be, they could either set sys.vm to the same value as one of the
existing interpreters and try to match the implementation details as
well as the language spec, or else use their own name.
History
Date User Action Args
2008-10-30 22:33:40ncoghlansetrecipients: + ncoghlan, brett.cannon, arigo, Carl.Friedrich.Bolz, benjamin.peterson
2008-10-30 22:33:40ncoghlansetmessageid: <1225406020.38.0.596099804876.issue4242@psf.upfronthosting.co.za>
2008-10-30 22:32:40ncoghlanlinkissue4242 messages
2008-10-30 22:32:38ncoghlancreate