This uses the new "restricted" feature of structmember, and getset
descriptors for some of the type checks.

compile() becomes replacement for builtin compile()
compileFile() generates a .pyc from a .py
both are exported in __init__

compiler.parse() gets optional second argument to specify compilation
mode, e.g. single, eval, exec

Add AbstractCompileMode as parent class and Module, Expression, and
Interactive as concrete subclasses.  Each corresponds to a compilation
mode.

THe AbstractCompileMode instances in turn delegate to CodeGeneration
subclasses specialized for their particular functions --
ModuleCodeGenerator, ExpressionCodeGeneration,
InteractiveCodeGenerator.

The argument properties are ordered from easiest to hardest.  The
harder the arg, the more complicated that code that must be generated
to return it from getChildren() and/or getChildNodes().  The old
calculation routine was bogus, because it always set hardest_arg to
the hardness of the last argument.  Now use max() to always set it to
the hardness of the hardest argument.

Remove the only test in the syntax module.  It ends up that the
transformer must handle this error case.

In the transformer, check for a list compression in com_assign_list()
by looking for a list_for node where a comma is expected.

In pycodegen.compile() re-raise the SyntaxError rather than catching
it and exiting

Renamed the 'readonly' field to 'flags' and defined some new flag
bits: READ_RESTRICTED and WRITE_RESTRICTED, as well as a shortcut
RESTRICTED that means both.

If passed a .py file as an argument, try to find its accompanying
.pyc.

Invoke compiler.syntax.check() after building AST.  If a SyntaxError
occurs, print the error and exit without generating a .pyc file.

Refactor code to use compiler.misc.set_filename() rather than passing
filename argument around to each CodeGenerator instance.

    module on the Cygwin platform.

   Once upon a time, I put together a little function
   that tries to find the canonical filename for a given
   pathname on POSIX. I've finally gotten around to
   turning it into a proper patch with documentation.
   On non-POSIX, I made it an alias for 'abspath', as
   that's the behavior on POSIX when no symlinks are
   encountered in the path.

   Example:
   >>> os.path.realpath('/usr/bin/X11/X')
   '/usr/X11R6/bin/X'

supplied values are the most "normal" or "common" values found for
recent 32 bit machines.  This now seems to work to build Python 2.2
for the ARM processor used on the iPAQ.

and are lists, and then just the string elements (if any)).

There are good and bad reasons for this.  The good reason is to support
dir() "like before" on objects of extension types that haven't migrated
to the class introspection API yet.  The bad reason is that Python's own
method objects are such a type, and this is the quickest way to get their
im_self etc attrs to "show up" via dir().  It looks much messier to move
them to the new scheme, as their current getattr implementation presents
a view of their attrs that's a untion of their own attrs plus their
im_func's attrs.  In particular, methodobject.__dict__ actually returns
methodobject.im_func.__dict__, and if that's important to preserve it
doesn't seem to fit the class introspection model at all.

    type(x) is T
tests with
    isinstance(x, T)
Also got rid of a future-generators import, left over from code that
wasn't intended to get checked in.

introspection incompatibility, but in fact it's just that calltips
always gave up on a docstring that started with a newline (but
didn't realize they were giving up <wink>).

Rewrote the 'p' description.

little test to make sure it doesn't come back.

Both int and long multiplication are changed to be more careful in
their assumptions about when one of the arguments is a sequence: the
assumption that at least one of the arguments must be an int (or long,
respectively) is still held, but the assumption that these don't smell
like sequences is no longer true: a subtype of int or long may well
have a sequence-repeat thingie!

and count exceed 255.  Changed to preserve as much of the string as
possible (instead of count%256 characters).

the compiler package generates a module-unique trailing suffix for
each lambda

Remove the option to have nested scopes or old LGB scopes.  This has a
large impact on the code base, by removing the need for two variants
of each CodeGenerator.

Add a get_module() method to CodeGenerator objects, used to get the
future features for the current module.

Set CO_GENERATOR, CO_GENERATOR_ALLOWED, and CO_FUTURE_DIVISION flags
as appropriate.

Attempt to fix the value of nlocals in newCodeObject(), assuming that
nlocals is 0 if CO_NEWLOCALS is not defined.

bound.

When a Yield() node is visited, assign to the generator attribute of
the scope, not the visitor.

ideas about sizeof(long).

The chief effects are to make dir() do something useful and supply
them with an __class__.

Allow staticbase != type, as long as their tp_new slots are the same.

NotImplemented when the lookup fails, and use this for binary
operators.  Also lookup_maybe() which doesn't raise an exception when
the lookup fails (still returning NULL).

- Don't turn a non-tuple argument into a one-tuple.  Rather, the
  caller must pass a format that causes Py_VaBuildValue() to return a
  tuple.

- Speed things up by calling PyObject_Call (which is fairly low-level
  and straightforward) rather than PyObject_CallObject (which calls
  PyEval_CallObjectWithKeywords which calls PyObject_Call, and nothing
  is really done in the mean time except some tests for NULL args and
  valid types, which are already guaranteed).

- Cosmetics.

Other places:

- Make sure that the format argument to call_method() is surrounded by
  parentheses, so it will cause a tuple to be created.

- Replace a few calls to PyEval_CallObject() with a surefire tuple for
  args to calls to PyObject_Call().  (A few calls to
  PyEval_CallObject() remain that have NULL for args.)

directly, as the only thing done here (replace NULL args with an empty
tuple) is also done there.

XXX Maybe we should take one step further and equate the two at the
macro level?  That's harder though because PyEval_Call* is declared in
a header that's not included standard.  But it is silly that
PyObject_CallObject calls PyEval_CallObject which calls back to
PyObject_Call.  Maybe PyEval_CallObject should be moved into this file
instead?  All I know is that there are too many call APIs!  The
differences between PyObject_Call and PyEval_CallObjectWithKeywords is
that the latter allows args to be NULL, and does explicit type checks
for args and kwds.