Undocumented syntax {} = {:} since v2.5.0

[jayvdb]

Prior to v2.5, {} was invalid. Since v2.5, it has become {:} to resolve to os.pathsep, because 9463f8f placed the logic before the following check for "no substitution type", rendering it dead code

        try:
            sub_type = g['sub_type']
        except KeyError:
            raise tox.exception.ConfigError(
                "Malformed substitution; no substitution type provided")

Given how long {} has been valid, perhaps it should be documented as-is, and tests added for {} being os.pathsep. Maybe noted as deprecated and will become invalid in v4.

However even if {} is kept as-is, the above ConfigError is unreachable code, so it should be removed.

I would prefer that we reject {} in v3 with a specific error message that {:} should be used instead. Rejecting {} simplifies/tighens the parsing logic, especially when approaching escaping { and } for #1708 .

[jayvdb]

I would prefer that we reject {} in v3 with a specific error message that {:} should be used instead.

@gaborbernat @asottile @obestwalter , could you comment on whether this is acceptable in v3. It is likely there are a few users which have used this undocumented {}, but it is easy for them to use {:} instead. Having two ways to achieve the same thing is bad, and {} being {:} is not intuitive.

Rejecting {} allows me to finish other PRs with less effort, and cleaner code.

[gaborbernat]

Rejecting {} allows me to finish other PRs with less effort, and cleaner code.

👍

[jayvdb]

There is also a related parsing problem, that I'll fix at the same time.
{:abc} on master causes

ConfigError: substitution key '' not found

g = {'default_value': 'abc', 'sub_type': None, 'substitution_value': ''} falls through to the bottom of _replace_match, invoking _replace_substitution, which then calls _substitute_from_other_section with an empty key.

ftr, the try/except block dates back to 2f98ebb (pre v1.0), but it appears to have taken a turn for the worse at 0068c4d (v1.2), likely resulting varying outcomes as other parts of the logic changed over time. The fact this hasnt been reported as a bug suggests the syntax has generally been intuitive enough, and/or users are not bothered by odd results and fix their syntax rather than rasing a bug.