Michael Hudson <mwh@python.net> writes:
> Here's a fairly short pre-PEP on the issue. If I haven't made any
> gross editorial blunders, can Barry give it a number and check the
> sucker in?
And here's a diff between what I posted and what I now have:
*** micro-pep1 Wed Aug 8 05:00:36 2001
--- micro-pep Wed Aug 8 05:08:16 2001
***************
*** 1,13 ****
PEP: XXXX
Title: Supporting __future__ statements in simulated shells
! Version: $Version:$
Author: Michael Hudson <mwh@python.net>
Status: Draft
Type: Standards Track
Requires: 0236
Created: 30-Jul-2001
Python-Version: 2.2
! Post-History:
Abstract
--- 1,13 ----
PEP: XXXX
Title: Supporting __future__ statements in simulated shells
! Version: 2
Author: Michael Hudson <mwh@python.net>
Status: Draft
Type: Standards Track
Requires: 0236
Created: 30-Jul-2001
Python-Version: 2.2
! Post-History: 30-Jul-2001
Abstract
***************
*** 24,39 ****
Specification
I propose adding a fourth, optional, "flags" argument to the
! builtin "compile" function. If this argument is omitted, there
! will be no change in behaviour from that of Python 2.1.
If it is present it is expected to be an integer, representing
various possible compile time options as a bitfield. The
bitfields will have the same values as the PyCF_* flags #defined
! in Include/pythonrun.h (at the time of writing there are only two
! - PyCF_NESTED_SCOPES and PyCF_GENERATORS). These are currently
! not exposed to Python, so I propose adding them to codeop.py
! (because it's already here, basically).
XXX Should the supplied flags be or-ed with the flags of the
calling frame, or do we override them? I'm for the former,
--- 24,39 ----
Specification
I propose adding a fourth, optional, "flags" argument to the
! builtin "compile" function. If this argument is omitted,
! there will be no change in behaviour from that of Python 2.1.
If it is present it is expected to be an integer, representing
various possible compile time options as a bitfield. The
bitfields will have the same values as the PyCF_* flags #defined
! in Include/pythonrun.h (at the time of writing there are three -
! PyCF_NESTED_SCOPES, PyCF_GENERATORS and PyCF_DIVISION). These are
! currently not exposed to Python, so I propose adding them to
! codeop.py (because it's already here, basically).
XXX Should the supplied flags be or-ed with the flags of the
calling frame, or do we override them? I'm for the former,
***************
*** 77,87 ****
statement is added. Such events will hopefully be very rare, so
such a burden is unlikely to cause significant pain.
Implementation
! None yet; none of the above should be at all hard. If this draft
! is well received, I'll upload a patch to sf "soon" and point to it
! here.
Copyright
--- 77,107 ----
statement is added. Such events will hopefully be very rare, so
such a burden is unlikely to cause significant pain.
+ Issues
+
+ Paul Prescod has reasonably complained about the choice of a
+ bitfield as the fourth argument to compile(), claiming it is
+ obscure and unpythonic.
+
+ There is also the thought of Jython compatibility; because Jython
+ has the ability to access any Java object without the PyObject
+ cruft needed in CPython, Jython already has a Python-visible
+ CompilerFlags object which has a boolean attribute
+ "compiler_flags", and will presumably have one fairly soon called
+ "generators". This would be doable in CPython, but it would
+ require more hacking of deep magical bits of the interpreter and
+ require bumping the PYTHON_API_VERSION (OTOH, the division patch
+ just went in, so there can't be a freeze on the C API just
+ yet...).
+
Implementation
! I've uploaded a preliminary implementation as:
!
! http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449043&group_id=5470
!
! I need to add docs and possibly implment a friendlier interface to
! compile().
Copyright
Basically I want to know if I have licence to go mucking around in the
PyEval_ interface and objects, doing things like making
PyCompilerFlags a PyObject and changing it's fields.
Cheers,
M.
--
59. In English every word can be verbed. Would that it were so in
our programming languages.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4