[Patches] [ python-Patches-929502 ] Remove ROT_FOUR

SourceForge.net noreply at sourceforge.net
Wed Apr 7 12:33:57 EDT 2004


Patches item #929502, was opened at 2004-04-04 22:01
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Chermside (mcherm)
Assigned to: Brett Cannon (bcannon)
Summary: Remove ROT_FOUR

Initial Comment:
I'll apologize in advance for the excessively lengthy
description here.

This patch results from an observation that Brett made
during the PyCon sprints... that the ROT_FOUR opcode is
only used in one incredibly obscure situation...
augmented slice assignment (and then only when the
slice has exactly 2 arguments). In case it's not
obvious what augmented slice assignment IS, here's an
example:

>>> x = range(6)
>>> x[2:4] += 'abc'
>>> x
[0, 1, 2, 3, 'a', 'b', 'c', 4, 5]

The feature needs to be supported but is of no
practical use whatsoever. Thus, one could ALMOST say
that the ROT_FOUR opcode is never used in Python.

Meanwhile, Raymond and others are hard at work trying
to squeeze better performance out of Python, and every
time they propose adding a new opcode or fiddling with
the core interpreter loop, someone somewhere complains
about cache effects. If we could drop support for some
completely unused opcode, then it might give Raymond
and others enough elbow room to do something truly useful.

So this patch re-implements augmented slice assignment
WITHOUT using ROT_FOUR (some fancy stack juggling and a
temporary tuple do the trick).

I'll leave it to others to decide whether it is worth
keeping the ROT_FOUR opcode around "just because we
might need it someday" (I'll note that we dropped
ROT_FIVE and ROT_SIX some time ago as they were never
used). But keeping it around just to support augmented
assignments is no longer an issue.

I tried to update everything relevent (ceval and
compile obviously, but also docs, the compiler package
and a mention in NEWS). I did NOT, however, update a
version number for the changed bytecodes, since I'm not
sure where such a thing lives (although SOMETHING must
be changed whenever a new release has modified the
opcodes). 

One technical note: I apologize for not using a context
diff. If someone can give me pointers on how to do that
on Windows (I've been using Tortoise CVS) I'll re-run
the diff.

And finally... after hanging around here for a number
of years, this is my first half-way decent patch
submission! Thanks to everyone at the PyCon sprints who
helped get me set up and compiling.

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2004-04-07 12:33

Message:
Logged In: YES 
user_id=99874

It's fairly easy to run a context diff between two files, what 
I'm not sure how to do is to run a context diff over the entire 
tree, comparing my files against those in CVS and collecting 
the results into a single diff file. I can do that with a 
command-line CVS, but I'm not sure how to do it with the 
tools I have on Windows.

I suppose I could modify diff.py so it was capable of  
comparing two trees, but then I'd need to keep an extra up-
to-date copy of the entire python CVS tree on my drive to 
compare against. Seems like there's gotta be a better solution.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-04-06 22:14

Message:
Logged In: YES 
user_id=357491

I think you can actually use the difflib module from the stdlib.  The docs 
say that Tools/scripts/diff.py is a front-end for doing this on files.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=929502&group_id=5470



More information about the Patches mailing list