| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
The new PyParser_*Ex() functions are based on Neal's suggestion and initial patch. The new __future__ feature makes all '' and r'' unicode strings. b'' and br'' stay (byte) strings.
|
| |
|
|
|
|
|
|
| |
This work is substantially Anthony Baxter's, from issue
1633807. I just freshened it, made a few minor tweaks,
and added the test cases. I also created issue 2412,
which is to check for 2to3's behavior with the print
function. I also added myself to ACKS.
|
| | |
|
| | |
|
| |
|
|
| |
were both added before a1
|
| |
|
|
| |
Neal.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| | |
|
| |
|
|
| |
compiler-flag argument).
|
| |
|
|
|
| |
__future__.py reverted to 1.9.
newmodule.c reverted to 2.32.
|
| |
|
|
| |
reported by Greg Ball on python-dev.
|
| |
|
|
|
|
|
|
|
|
| |
right way"). Fiddle __future__.py to use them.
Jeremy's pyassem.py may also want to use them (by-hand duplication of
magic numbers is brittle), but leaving that to his judgment.
Beef up __future__'s test to verify the exported feature names appear
correct.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
#449043 supporting __future__ in simulated shells
in support of PEP 264.
Much has changed from the patch version:
+ Repaired bad hex constant for nested_scopes.
+ Defined symbolic CO_xxx names so global search will find these uses.
+ Made the exported list of feature names explicit, instead of abusing
__all__ for this purpose (and redefined __all__ accordingly).
+ Added gross .compiler_flag verification to test___future__.py, and
reworked it a little to make use of the newly exported explicit list
of feature names.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
the yield statement. I figure we have to have this in before I can
release 2.2a1 on Wednesday.
Note: test_generators is currently broken, I'm counting on Tim to fix
this.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Suggested on c.l.py by William Tanksley, and I like it.
|
| | |
|
|
|
therein are of the proper form.
|
