summaryrefslogtreecommitdiff
path: root/Lib/__future__.py
Commit message (Collapse)AuthorAgeFilesLines
* PEP 479: Change StopIteration handling inside generators.Yury Selivanov2015-05-091-0/+6
| | | | Closes issue #22906.
* #14494: Document that absolute imports became default in 3.0 instead of 2.7.Petri Lehtinen2012-05-191-1/+1
|
* barry has already been causing test breakageBenjamin Peterson2009-04-011-0/+1
|
* The BDFL has retired! Long live the FLUFL (Friendly Language Uncle For Life)!Brett Cannon2009-04-011-0/+5
|
* Merged revisions 61952-61953 via svnmerge fromChristian Heimes2008-03-261-0/+6
| | | | | | | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r61952 | mark.dickinson | 2008-03-26 22:41:36 +0100 (Wed, 26 Mar 2008) | 2 lines Typo: "objects reference count" -> "object's reference count" ........ r61953 | christian.heimes | 2008-03-26 23:01:37 +0100 (Wed, 26 Mar 2008) | 4 lines Patch #2477: Added from __future__ import unicode_literals 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. ........
* Add __future__ import for print_function. It's a no-op in 3.0, but it needs ↵Eric Smith2008-03-201-0/+6
| | | | | | to not be a syntax error. Closes issue 2436.
* Merge p3yk branch with the trunk up to revision 45595. This breaks a fairThomas Wouters2006-04-211-2/+2
| | | | | | | | | | | | | | | | | | | | number of tests, all because of the codecs/_multibytecodecs issue described here (it's not a Py3K issue, just something Py3K discovers): http://mail.python.org/pipermail/python-dev/2006-April/064051.html Hye-Shik Chang promised to look for a fix, so no need to fix it here. The tests that are expected to break are: test_codecencodings_cn test_codecencodings_hk test_codecencodings_jp test_codecencodings_kr test_codecencodings_tw test_codecs test_multibytecodec This merge fixes an actual test failure (test_weakref) in this branch, though, so I believe merging is the right thing to do anyway.
* Make __future__ features similar for with and absolute import since they ↵Neal Norwitz2006-02-281-2/+2
| | | | were both added before a1
* from __future__ import with_statement addon for 'with', mostly written byThomas Wouters2006-02-281-0/+6
| | | | Neal.
* SF patch #1438387, PEP 328: relative and absolute imports.Thomas Wouters2006-02-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | - 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.
* Finish removal of CO_GENERATOR_ALLOWED.Neal Norwitz2006-02-271-1/+1
|
* Repair repr of future-features (wasn't updated to include the newTim Peters2001-08-241-2/+3
| | | | compiler-flag argument).
* Back out trying to use the C values for CO_xxx.Tim Peters2001-08-241-10/+10
| | | | | __future__.py reverted to 1.9. newmodule.c reverted to 2.32.
* Avoid total dependency on the new module. This addresses the problemGuido van Rossum2001-08-191-1/+7
| | | | reported by Greg Ball on python-dev.
* Expose the CO_xxx flags via the "new" module (re-solving a problem "theTim Peters2001-08-181-11/+4
| | | | | | | | | | 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.
* A self-contained piece of Michael Hudson's patchTim Peters2001-08-171-7/+40
| | | | | | | | | | | | | | #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.
* Implement PEP 238 in its (almost) full glory.Guido van Rossum2001-08-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Preliminary support for "from __future__ import generators" to enableGuido van Rossum2001-07-151-0/+1
| | | | | | | | 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.
* Remove now-unnecessary "from __future__ import nested_scopes" stmts.Tim Peters2001-07-121-1/+1
|
* Remove redundant "__future__:" from module docstring.Ka-Ping Yee2001-03-151-1/+1
|
* Typo repair.Tim Peters2001-03-021-1/+1
|
* Make names in __future__.py bind to class instances instead of 2-tuples.Tim Peters2001-03-021-7/+32
| | | | Suggested on c.l.py by William Tanksley, and I like it.
* Whitespace normalization.Tim Peters2001-02-281-4/+4
|
* Add __future__.py to std library, + dull test to verify that assignmentsTim Peters2001-02-261-0/+44
therein are of the proper form.