You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Is --target-version the minimum or should all be explicitly listed? #751
With old Black 18.9b0, I had this in pyproject.toml:
[tool.black]
py36 = true
The new Black 19.3b0 warns:
--py36 is deprecated and will be removed in a future version. Use --target-version py36 instead.
The docs say:
-t, --target-version [py27|py33|py34|py35|py36|py37|py38]
Python versions that should be supported by
Black's output. [default: per-file auto-
detection]
--py36 Allow using Python 3.6-only syntax on all
input files. This will put trailing commas
in function signatures and calls also after
*args and **kwargs. Deprecated; use
--target-version instead. [default: per-file
auto-detection]
You should include all Python versions that you want your code to run under. In practice, though, 3.6 through 3.8 are currently the same as far as Black is concerned, so either variant will do the same.
Let us know if you think the docs can be improved.
Jelle, I get that certain edge cases in the grammar are only available in the newer versions, so we need the lower bound. Why do we need the upper bound, too?
FWIW I just had to look into black's source cod too, to figure out how to set target-version.
From the docs it's unclear that it takes multiple versions and reusing --target-version=py36 as target-version=py36 fails with confusing errors.
I think it's fine to allow supplying a range (although I'd prefer something like py27...py38 or py37... that conveys the meaning better), but the docs don't reflect that currently.
Reacted by Hugo van Kemenade, Zac Hatfield-Dodds, jfarshankar, Erik Sundell, Turbo Coder and Toluwaleke Ogundipe
These are pretty long, and it'd be nice to have a shorter range argument (or just a single lower bound).
I'm also curious why we need the upper bound. In practice, 3.5-3.8 is currently the same as just 3.5. What sort of theoretical cases are there where it'd be different?
I'm also curious why we need the upper bound. In practice, 3.5-3.8 is currently the same as just 3.5. What sort of theoretical cases are there where it'd be different?
In theory, a new version of Python could change the syntax such that a kind of formatting that Black thinks is ideal is no longer supported. As a hypothetical example, maybe Python 3.9 will decide that all string prefixes have to be uppercase, so f"{x}" will be SyntaxError and only F"{x}" will be legal. In that case, if you set target_version to 3.5-3.8, we'd still emit f"{x}" (because Black's style prefers lowercase string prefixes), but with 3.5-3.9 we'd have to emit F"{x}".
In practice that sort of scenario doesn't seem terribly likely, so I'd be OK with making target_version just a minimum requirement.
Reacted by Hugo van Kemenade, Jon Dufresne and Marcin Malinowski
At the same time I agree that it should almost certainly be 3.6+, 3.7+, 3.8+, and so on. But Jelle's got a point about possible syntax breaking changes in the future. I'm not sure if we should make this change.
I'd hope the answer is "Python 2 taught us not to make breaking changes to the syntax" - and if we do, adding an optional --maximum-version argument will be the least of the problems dumped on the library ecosystem.
My suggestion would be to read project.requires-python from pyproject.toml; you can compare using packaging.specifiers to see what the allowed versions are. cibuildwheel 1.9 does this. Since PEP 621, that is the canonical place for this information, and powerful enough to provide a subset or limit if needed.
if you set target_version to 3.5-3.8, we'd still emit f"{x}" (because Black's style prefers lowercase string prefixes), but with 3.5-3.9 we'd have to emit F"{x}".
This doesn't apply for python 3.3 does it? Black still outputs f-strings even though they are not supported.
These are pretty long, and it'd be nice to have a shorter range argument (or just a single lower bound).
You can alternatively write the yaml with the arguments stacked in a vertical list instead, which I think is a lot easier to read when you're specifying more than three versions for black to target.
@JelleZijlstra and I have decided to make --target-version the minimum. It better fits user expectations and it's the only way to reasonably support #3124. We'll still need to decide how specifying a single vs multiple versions will work though.
Reacted by Ville Skyttä, Zac Hatfield-Dodds, Laurent Sorber and Yilei
While implementing #3489, I came up with another need: a project may want to set a minimum version but still allow auto detecting target version when it uses newer syntaxes from later versions.
A concrete example: a projects supports Python 3.9+, but it may still contain some files with pattern matching syntax (a common case is its test files, it wants to make sure it works with pattern matching, but the test only runs on Python 3.10+).
Without specifying a minimum version of 3.9, it can't use parenthesized context managers (when the file doesn't contain syntaxes from 3.9+). But setting --target-version=3.9 today would make it fail to parse 3.10+ syntaxes.
@JelleZijlstra and I have decided to make --target-version the minimum. It better fits user expectations and it's the only way to reasonably support #3124. We'll still need to decide how specifying a single vs multiple versions will work though.
Is it safe to say that thought it has been decided and has not been implemented? My interpretation of this thread is that current commendation for py38-py311 support would be:
Any updates on this thread? I would also prefer specifying only the minimum version as it doesn't require using a bleeding edge version of black just to have it recognize 'py312' as a valid target version.
Activity
JelleZijlstra commentedon Mar 14, 2019
You should include all Python versions that you want your code to run under. In practice, though, 3.6 through 3.8 are currently the same as far as Black is concerned, so either variant will do the same.
Let us know if you think the docs can be improved.
ambv commentedon Mar 14, 2019
Jelle, I get that certain edge cases in the grammar are only available in the newer versions, so we need the lower bound. Why do we need the upper bound, too?
hynek commentedon Mar 16, 2019
FWIW I just had to look into black's source cod too, to figure out how to set target-version.
From the docs it's unclear that it takes multiple versions and reusing
--target-version=py36astarget-version=py36fails with confusing errors.I think it's fine to allow supplying a range (although I'd prefer something like
py27...py38orpy37...that conveys the meaning better), but the docs don't reflect that currently.hugovk commentedon Nov 1, 2019
Another confusion.
Let's say I support Python 3.5-3.8 so have this in
pyproject.toml:If I don't have this config file and want to do the same thing directly on the command line, do I need to repeat each argument?
$ black --target-version py35 --target-version py36 --target-version py37 --target-version py38 .And then would
.pre-commit.yamlneed to look like this?These are pretty long, and it'd be nice to have a shorter range argument (or just a single lower bound).
I'm also curious why we need the upper bound. In practice, 3.5-3.8 is currently the same as just 3.5. What sort of theoretical cases are there where it'd be different?
Thanks!
JelleZijlstra commentedon Nov 1, 2019
In theory, a new version of Python could change the syntax such that a kind of formatting that Black thinks is ideal is no longer supported. As a hypothetical example, maybe Python 3.9 will decide that all string prefixes have to be uppercase, so
f"{x}"will be SyntaxError and onlyF"{x}"will be legal. In that case, if you set target_version to 3.5-3.8, we'd still emitf"{x}"(because Black's style prefers lowercase string prefixes), but with 3.5-3.9 we'd have to emitF"{x}".In practice that sort of scenario doesn't seem terribly likely, so I'd be OK with making target_version just a minimum requirement.
Zac-HD commentedon Dec 29, 2019
I was very surprised to discover it wasn't already a minimum requirement, and that only happened when I stumbled across this issue!
FWIW I think making forward-compatibilty the easy option is also better for the ecosystem 😄
ambv commentedon Mar 4, 2020
At the same time I agree that it should almost certainly be 3.6+, 3.7+, 3.8+, and so on. But Jelle's got a point about possible syntax breaking changes in the future. I'm not sure if we should make this change.
Zac-HD commentedon Mar 5, 2020
I'd hope the answer is "Python 2 taught us not to make breaking changes to the syntax" - and if we do, adding an optional
--maximum-versionargument will be the least of the problems dumped on the library ecosystem.henryiii commentedon Feb 12, 2021
My suggestion would be to read
project.requires-pythonfrom pyproject.toml; you can compare using packaging.specifiers to see what the allowed versions are.cibuildwheel1.9 does this. Since PEP 621, that is the canonical place for this information, and powerful enough to provide a subset or limit if needed.See https://github.com/joerick/cibuildwheel/blob/58c5e56e9f271e32020b687f62cc02003602edd2/cibuildwheel/__main__.py#L173 and https://github.com/joerick/cibuildwheel/blob/58c5e56e9f271e32020b687f62cc02003602edd2/cibuildwheel/util.py#L77
deathaxe commentedon May 23, 2021
This doesn't apply for python 3.3 does it? Black still outputs f-strings even though they are not supported.
JelleZijlstra commentedon May 23, 2021
Black doesn't support Python 3.3. Also, note that you're quoting a hypothetical out of context.
scottclowe commentedon Jun 28, 2021
@hugovk
You can alternatively write the yaml with the arguments stacked in a vertical list instead, which I think is a lot easier to read when you're specifying more than three versions for black to target.
add all black target-versions
Add support for py3.6 and py3.9 (#26)
set black min target-version to py36 (#896)
ichard26 commentedon Jun 28, 2022
@JelleZijlstra and I have decided to make --target-version the minimum. It better fits user expectations and it's the only way to reasonably support #3124. We'll still need to decide how specifying a single vs multiple versions will work though.
yilei commentedon Jan 20, 2023
While implementing #3489, I came up with another need: a project may want to set a minimum version but still allow auto detecting target version when it uses newer syntaxes from later versions.
A concrete example: a projects supports Python 3.9+, but it may still contain some files with pattern matching syntax (a common case is its test files, it wants to make sure it works with pattern matching, but the test only runs on Python 3.10+).
Without specifying a minimum version of 3.9, it can't use parenthesized context managers (when the file doesn't contain syntaxes from 3.9+). But setting --target-version=3.9 today would make it fail to parse 3.10+ syntaxes.
Add all supported Python versions to black config
itdependsnetworks commentedon Aug 28, 2023
Is it safe to say that thought it has been decided and has not been implemented? My interpretation of this thread is that current commendation for py38-py311 support would be:
In the future it would be equivalent of:
adamjstewart commentedon Mar 13, 2024
Any updates on this thread? I would also prefer specifying only the minimum version as it doesn't require using a bleeding edge version of black just to have it recognize
'py312'as a valid target version.