Commit Graph

28 Commits

Author SHA1 Message Date
Miss Islington (bot) b99f770230
bpo-41314: fixed annotations __future__ version (GH-21616)
PEP 563 was updated to change the release where `from __future__ import annotations` becomes the default (and only) behavior from 4.0 to 3.10. Update `__future__.py` and its docs to reflect this.
(cherry picked from commit 0028c14073)

Co-authored-by: YoSTEALTH <35307184+YoSTEALTH@users.noreply.github.com>
2020-07-25 15:00:17 -07:00
Pablo Galindo 5055c274c6
[3.8] bpo-39562: Prevent collision of future and compiler flags (GH-19230) (GH-19835)
The constant values of future flags in the __future__ module
is updated in order to prevent collision with compiler flags.
Previously PyCF_ALLOW_TOP_LEVEL_AWAIT was clashing
with CO_FUTURE_DIVISION..
(cherry picked from commit 4454057269)

Co-authored-by: Batuhan Taşkaya <batuhanosmantaskaya@gmail.com>
2020-05-01 07:18:27 -07:00
Chris Rands 55cc34500e bpo-35526: make __future__.barry_as_FLUFL mandatory for Python 4.0 (#11218)
* extending the joke!

* 📜🤖 Added by blurb_it.
2018-12-19 08:19:39 -08:00
Guido van Rossum 95e4d58913 String annotations [PEP 563] (#4390)
* Document `from __future__ import annotations`
* Provide plumbing and tests for `from __future__ import annotations`
* Implement unparsing the AST back to string form

This is required for PEP 563 and as such only implements a part of the
unparsing process that covers expressions.
2018-01-26 08:20:18 -08:00
Yury Selivanov 8170e8c0d1 PEP 479: Change StopIteration handling inside generators.
Closes issue #22906.
2015-05-09 11:44:30 -04:00
Petri Lehtinen 079bfc962d #14494: Document that absolute imports became default in 3.0 instead of 2.7. 2012-05-19 18:36:33 +03:00
Benjamin Peterson 91d7dfd77c barry has already been causing test breakage 2009-04-01 20:38:13 +00:00
Brett Cannon e3944a5e1e The BDFL has retired! Long live the FLUFL (Friendly Language Uncle For Life)! 2009-04-01 05:08:41 +00:00
Christian Heimes 4d6ec85a02 Merged revisions 61952-61953 via svnmerge from
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.
........
2008-03-26 22:34:47 +00:00
Eric Smith 87824086fa Add __future__ import for print_function. It's a no-op in 3.0, but it needs to not be a syntax error.
Closes issue 2436.
2008-03-20 23:02:08 +00:00
Thomas Wouters 49fd7fa443 Merge p3yk branch with the trunk up to revision 45595. This breaks a fair
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.
2006-04-21 10:40:58 +00:00
Neal Norwitz 9193491eb3 Make __future__ features similar for with and absolute import since they were both added before a1 2006-02-28 20:02:42 +00:00
Thomas Wouters 34aa7ba114 from __future__ import with_statement addon for 'with', mostly written by
Neal.
2006-02-28 19:02:24 +00:00
Thomas Wouters f7f438ba3b SF patch #1438387, PEP 328: relative and absolute imports.
- 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.
2006-02-28 16:09:29 +00:00
Neal Norwitz 0023a2f858 Finish removal of CO_GENERATOR_ALLOWED. 2006-02-27 23:24:48 +00:00
Tim Peters 16c018d2d2 Repair repr of future-features (wasn't updated to include the new
compiler-flag argument).
2001-08-24 17:13:54 +00:00
Tim Peters 89675078cb Back out trying to use the C values for CO_xxx.
__future__.py reverted to 1.9.
newmodule.c reverted to 2.32.
2001-08-24 06:29:12 +00:00
Guido van Rossum 8cb00e2387 Avoid total dependency on the new module. This addresses the problem
reported by Greg Ball on python-dev.
2001-08-19 05:29:25 +00:00
Tim Peters aa32070f4d Expose the CO_xxx flags via the "new" module (re-solving a problem "the
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.
2001-08-18 20:18:49 +00:00
Tim Peters de642bdc5d A self-contained piece of Michael Hudson's patch
#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.
2001-08-17 19:49:02 +00:00
Guido van Rossum 4668b000a1 Implement PEP 238 in its (almost) full glory.
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.
2001-08-08 05:00:18 +00:00
Guido van Rossum b09f7ed623 Preliminary support for "from __future__ import generators" to enable
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.
2001-07-15 21:08:29 +00:00
Tim Peters c4889c496a Remove now-unnecessary "from __future__ import nested_scopes" stmts. 2001-07-12 22:36:02 +00:00
Ka-Ping Yee 3bda4f0878 Remove redundant "__future__:" from module docstring. 2001-03-15 10:45:44 +00:00
Tim Peters fd85a4e600 Typo repair. 2001-03-02 03:11:53 +00:00
Tim Peters d74bc432b2 Make names in __future__.py bind to class instances instead of 2-tuples.
Suggested on c.l.py by William Tanksley, and I like it.
2001-03-02 02:53:08 +00:00
Tim Peters 85ba673b0a Whitespace normalization. 2001-02-28 08:26:44 +00:00
Tim Peters ffc215a279 Add __future__.py to std library, + dull test to verify that assignments
therein are of the proper form.
2001-02-26 21:14:49 +00:00