| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
| |
Emit a deprecation warning if the numeric literal is immediately followed by
one of keywords: and, else, for, if, in, is, or. Raise a syntax error with
more informative message if it is immediately followed by other keyword or
identifier.
Automerge-Triggered-By: GH:pablogsal
|
| |
|
|
|
|
|
| |
classes and modules (#25623)
Change class and module objects to lazy-create empty annotations dicts on demand. The annotations dicts are stored in the object's `__dict__` for backwards compatibility.
|
|
|
|
|
|
| |
(GH-25490)
This reverts commits 044a1048ca93d466965afc027b91a5a9eb9ce23c and 1be456ae9d53bb1cba2b24fc86175c282d1c2169, adapting the code to changes that happened after it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* bpo-43497: Emit SyntaxWarnings for assertions with tuple constants.
Add a test that shows that a tuple constant (a tuple, where all of its
members are also compile-time constants) produces a SyntaxWarning. Then
fix this failure.
* Make SyntaxWarnings also work when "optimized".
* Split tests for SyntaxWarning to SyntaxError conversion
SyntaxWarnings emitted by the compiler when configured to be errors are
actually raised as SyntaxError exceptions.
Move these tests into their own method and add a test to ensure they are
raised. Previously we only tested that they were not raised for a
"valid" assertion statement.
|
| |
|
|
|
|
|
| |
The hard part was making all the tests pass; there are some subtle issues here, because apparently the future import wasn't tested very thoroughly in previous Python versions.
For example, `inspect.signature()` returned type objects normally (except for forward references), but strings with the future import. We changed it to try and return type objects by calling `typing.get_type_hints()`, but fall back on returning strings if that function fails (which it may do if there are future references in the annotations that require passing in a specific namespace to resolve).
|
|
|
|
| |
Clinic (GH-21535)
|
| |
|
|
|
| |
This commit removes the old parser, the deprecated parser module, the old parser compatibility flags and environment variables and all associated support code and documentation.
|
|
|
|
|
|
|
|
|
| |
This commit fixes the new parser to disallow invalid targets in the
following scenarios:
- Augmented assignments must only accept a single target (Name,
Attribute or Subscript), but no tuples or lists.
- `except` clauses should only accept a single `Name` as a target.
Co-authored-by: Pablo Galindo <Pablogsal@gmail.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Fix compilation of "break" and "continue" in the
"finally" block when the corresponding "try" block
contains "return" with a non-constant value.
|
|
|
|
| |
(GH-13760)
|
| |
|
|
|
|
|
|
|
| |
It checks that a SyntaxWarning is raised when compile specified
statement, that it is raised only once, that it is converted to
a SyntaxError when raised as exception, and that both warning and
exception objects have corresponding attributes.
|
|
|
|
| |
(GH-11757)
|
|
|
|
|
|
| |
(GH-11667)
|
| |
|
|
|
|
| |
If SyntaxWarning was raised as an exception, it will be replaced
with a SyntaxError for better error reporting.
|
|
|
| |
Fixes warnings in tests added in bpo-32117 and bpo-34603.
|
|
|
|
|
| |
Iterable unpacking is now allowed without parentheses in yield and return
statements, e.g. ``yield 1, 2, 3, *rest``. Thanks to David Cuthbert for the
change and jChapman for added tests.
|
| |
|
| |
|
|
|
|
| |
(GH-4564)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(GH-4579)
The current behaviour of yield expressions inside comprehensions and
generator expressions is essentially an accident of implementation - it
arises implicitly from the way the compiler handles yield expressions inside
nested functions and generators.
Since the current behaviour wasn't deliberately designed, and is inherently
confusing, we're deprecating it, with no current plans to reintroduce it.
Instead, our advice will be to use a named nested generator definition
for cases where this behaviour is desired.
|
|
|
|
| |
Ivan L.
|
| |
|
|
|
|
| |
By Ivan Levkivskyi.
|
|
|
|
| |
Thanks to Georg Brandl for the patch.
|
|
|
|
| |
Patch by Ivan Levkivskyi.
|
|
|
|
| |
Patch by Demur Rumed.
|
|\ |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Patch written by Demur Rumed.
|
| |
| |
| |
| |
| | |
Issue #26204: the compiler doesn't emit SyntaxWarning warnings anymore when
constant statements are ignored.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The compile ignores constant statements and emit a SyntaxWarning warning.
Don't emit the warning for string statement because triple quoted string is a
common syntax for multiline comments.
Don't emit the warning on ellipis neither: 'def f(): ...' is a legit syntax for
abstract functions.
Changes:
* test_ast: ignore SyntaxWarning when compiling test statements. Modify
test_load_const() to use assignment expressions rather than constant
expression.
* test_code: add more kinds of constant statements, ignore SyntaxWarning when
testing that the compiler removes constant statements.
* test_grammar: ignore SyntaxWarning on the statement "1"
|
|/
|
|
|
|
| |
For example, "def f(*, a = 3,): pass" is now legal.
Patch from Mark Dickinson.
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit fixes how one-line async-defs and defs are tracked
by tokenizer. It allows to correctly parse invalid code such
as:
>>> async def f():
... def g(): pass
... async = 10
and valid code such as:
>>> async def f():
... async def g(): pass
... await z
As a consequence, is is now possible to have one-line
'async def foo(): await ..' functions:
>>> async def foo(): return await bar()
|