[Python-Dev] Changing the Division Operator -- PEP 238, rev 1.12

[Michael Hudson]

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