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.

classification
Title: Expose C level compiler flag constants to Python code
Type: enhancement Stage: needs patch
Components: Versions: Python 3.6, Python 3.5
process
Status: open Resolution:
Dependencies: 24400 Superseder:
Assigned To: Nosy List: gvanrossum, larry, ncoghlan, superluser, yselivanov
Priority: normal Keywords: patch

Created on 2015-06-19 04:47 by ncoghlan, last changed 2022-04-11 14:58 by admin.

Files
File name Uploaded Description Edit
code.patch yselivanov, 2015-06-19 17:22 review
opcode.patch yselivanov, 2015-06-20 20:37 review
Messages (8)
msg245487 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-06-19 04:47
As part of the PEP 492 implementation, Yury has needed to hardcode compile flag contants in various places, with adjacent comments explaining what the magic numbers mean.

It occurred to me that there's a way we could make those constants readily available to any code manipulating code objects: expose them as read-only attributes via the code object type.

Does this seem like a reasonable idea?

If yes, would it be reasonable to classify it as part of the PEP 492 implementation process and include it during the 3.5 beta cycle?
msg245488 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2015-06-19 04:48
Probably, though I want to see a sample implementation before I agree to anything.
msg245489 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-06-19 05:06
In my last set of review comments on issue 24400 I suggested changing the Python level attributes for coroutine objects to cr_frame, cr_code, and cr_running.

It's possible that may provide a different way to eliminate some of the current compiler flag checks.
msg245510 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2015-06-19 17:22
Nick, Larry, please take a look at the attached patch.
msg245541 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-06-20 05:32
Bringing a design discussion back from the code review, since I didn't explain the problem to be solved very well, and instead jumped straight to recommending a specific solution.

Currently, dis has a dictionary mapping from hardcoded compiler flag values (in decimal, no less!) to flag names. The inspect module then iterates over this dictionary at import time to publish the CO_* constants as module level attributes in inspect.

Neither dis.COMPILER_FLAG_NAMES nor the inspect.CO_* constants are documented, and the *C* level flag values aren't published to the Python layer anywhere (hence the hardcoding of the magic numbers in dis).

For the kind of code that needs to interrogate the flags in the issue 24400 patch, inspect and dis are also not appropriate things to adopt as dependencies.

However, I like Larry's suggestion of adopting the _opcode module as our standard vector for passing this information up from the C layer to the Python layer better than my original idea of using code objects themselves.

The opcode values themselves could potentially also be exposed that way (they're currently duplicated by hand in Lib/opcode.py).
msg245573 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2015-06-20 20:37
Larry, Nick,

Attached patch exposes CO* constants in the '_opcode' module.

There is one slight complication though: importing '_opcode' in 'types' (required for issue24400) breaks Python compilation, as 'types' module is used by many tools at the point where '_opcode' module isn't yet compiled.

We should either make '_opcode' compiled earlier or move constants to the 'sys' module.
msg245580 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-06-21 01:53
Making _opcode a builtin module rather than an extension module makes more sense to me than adding more random stuff to the sys module.
msg246115 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2015-07-03 00:56
opcode.patch is okay for 3.5.
History
Date User Action Args
2022-04-11 14:58:18adminsetgithub: 68656
2015-07-03 00:56:21larrysetmessages: + msg246115
2015-06-21 01:53:17ncoghlansetmessages: + msg245580
2015-06-20 20:37:25yselivanovsetfiles: + opcode.patch

messages: + msg245573
2015-06-20 05:32:06ncoghlansetmessages: + msg245541
title: Expose compiler flag constants as code object attributes -> Expose C level compiler flag constants to Python code
2015-06-20 02:06:13superlusersetnosy: + superluser
2015-06-19 17:22:36yselivanovsetfiles: + code.patch
keywords: + patch
messages: + msg245510
2015-06-19 05:06:39ncoghlansetmessages: + msg245489
2015-06-19 04:48:19larrysetmessages: + msg245488
2015-06-19 04:47:42ncoghlansetdependencies: + Awaitable ABC incompatible with functools.singledispatch
2015-06-19 04:47:33ncoghlancreate