with some help from Georg

[x for x in it if x if x], were broken for no good reason by the PEP 308
patch.

actually necessary for functionality, but good for transition.

 - IMPORT_NAME takes an extra argument from the stack: the relativeness of
   the import. Only passed to __import__ when it's not -1.

 - __import__() takes an optional 5th argument for the same thing; it
   __defaults to -1 (old semantics: try relative, then absolute)

 - 'from . import name' imports name (be it module or regular attribute)
   from the current module's *package*. Likewise, 'from .module import name'
   will import name from a sibling to the current module.

 - Importing from outside a package is not allowed; 'from . import sys' in a
   toplevel module will not work, nor will 'from .. import sys' in a
   (single-level) package.

 - 'from __future__ import absolute_import' will turn on the new semantics
   for import and from-import: imports will be absolute, except for
   from-import with dots.

Includes tests for regular imports and importhooks, parser changes and a
NEWS item, but no compiler-package changes or documentation changes.

This was started by Mike Bland and completed by Guido
(with help from Neal).

This still needs a __future__ statement added;
Thomas is working on Michael's patch for that aspect.

There's a small amount of code cleanup and refactoring
in ast.c, compile.c and ceval.c (I fixed the lltrace
behavior when EXT_POP is used -- however I had to make
lltrace a static global).

breaks the parser module, because it adds the if/else construct as well as
two new grammar rules for backward compatibility. If no one else fixes
parsermodule, I guess I'll go ahead and fix it later this week.

The TeX code was checked with texcheck.py, but not rendered. There is
actually a slight incompatibility:

>>> (x for x in lambda:0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: iteration over non-sequence

changes into

>>> (x for x in lambda: 0)
  File "<stdin>", line 1
    (x for x in lambda: 0)
                     ^
SyntaxError: invalid syntax

Since there's no way the former version can be useful, it's probably a
bugfix ;)

['(' gen_for ')'] is redundant with test, so remove it.

Modified since ast-arenas was implemented.

properties now.

Incorrect code was generated for:

  foo(a = i for i in range(10))

This should have generated a SyntaxError.  Fix the Grammar so
it raises a SyntaxError and test it.

I'm uncertain whether this should be backported.  It makes
something that was Syntactically valid invalid.  However,
the code would either be completely broken or do the wrong thing.

method still needs to support string exceptions, and allow None for the
third argument.  Documentation updates are needed, too.

``class C(): pass`` is no longer a syntax error.

"from blah import (foo, bar
baz, bongo)"

[ 1009560 ] Fix @decorator evaluation order

From the description:

Changes in this patch:

- Change Grammar/Grammar to require
newlines between adjacent decorators.

- Fix order of evaluation of decorators
in the C (compile.c) and python
(Lib/compiler/pycodegen.py) compilers

- Add better order of evaluation check
to test_decorators.py (test_eval_order)

- Update the decorator documentation in
the reference manual (improve description
of evaluation order and update syntax
description)

and the comment:

Used Brett's evaluation order (see
http://mail.python.org/pipermail/python-dev/2004-August/047835.html)

(I'm checking this in for Anthony who was having problems getting SF to
talk to him)

"@ seems the syntax that everybody can hate equally"
Implementation by Mark Russell, from SF #979728.

(Code contributed by Jiwon Seo.)

The documentation portion of the patch is being re-worked and will be
checked-in soon.  Likewise, PEP 289 will be updated to reflect Guido's
rationale for the design decisions on binding behavior (as described in
in his patch comments and in discussions on python-dev).

The test file, test_genexps.py, is written in doctest format and is
meant to exercise all aspects of the the patch.  Further additions are
welcome from everyone.  Please stress test this new feature as much as
possible before the alpha release.

The old syntax suggested that a trailing comma was OK inside backticks,
but in fact (due to ideosyncrasies of pgen) it was not.  Fix the grammar
to avoid the ambiguity.  Fred: you may want to update the refman.

"power" was formally ambiguous.  Here's his fix.

"for <var> in <testlist> may no longer be a single test followed by
a comma.  This solves SF bug #431886.  Note that if the testlist
contains more than one test, a trailing comma is still allowed, for
maximum backward compatibility; but this example is not:

    [(x, y) for x in range(10), for y in range(10)]
                              ^

The fix involved creating a new nonterminal 'testlist_safe' whose
definition doesn't allow the trailing comma if there's only one test:

    testlist_safe: test [(',' test)+ [',']]

This introduces:

- A new operator // that means floor division (the kind of division
  where 1/2 is 0).

- The "future division" statement ("from __future__ import division)
  which changes the meaning of the / operator to implement "true
  division" (where 1/2 is 0.5).

- New overloadable operators __truediv__ and __floordiv__.

- New slots in the PyNumberMethods struct for true and floor division,
  new abstract APIs for them, new opcodes, and so on.

I emphasize that without the future division statement, the semantics
of / will remain unchanged until Python 3.0.

Not yet implemented are warnings (default off) when / is used with int
or long arguments.

This has been on display since 7/31 as SF patch #443474.

Flames to /dev/null.

Bugfix candidate in inspect.py:  it was referencing "self" outside of
a method.

Michael Hudson, and support in general for the augmented assignment syntax.
The graminit.c patch is large!

changes to this file.

This change modifies Python's grammar to include the extended print
form.

name as n'. By doing some twists and turns, "as" is not a reserved word.

There is a slight change in semantics for 'from module import name' (it will
now honour the 'global' keyword) but only in cases that are explicitly
undocumented.

directory.

This closes patch:
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=101176&group_id=5470

    http://sourceforge.net/patch/?func=detailpatch&patch_id=100654&group_id=5470

for details.