Skip to content

Composable prompting protocol names: base[:version](+feature[:version])*. - #789

Merged
copybara-service[bot] merged 1 commit into
mainfrom
test_1008606157
Oct 30, 2026
Merged

copybara-service[bot] merged 1 commit into
mainfrom
test_1008606157

Conversation

@copybara-service

@copybara-service copybara-service Bot commented Oct 29, 2026 •

Copy link
Copy Markdown

Composable prompting protocol names: base[:version](+feature[:version])*.

Precursor for protocol features such as python+verbatim, which is the next
change. This one registers no feature, so existing names (python,
python:1.0, python:2.0, json, markdown, ...) prompt, parse and are
recorded exactly as before.

WHAT

  • One parser, ProtocolName.parse (schema/base.py), reads the grammar and
    normalizes a name: a feature without a version takes its default version,
    and features are ordered by rank, then by name, so the order does not depend
    on imports. Once the base version is filled in, a protocol has exactly one
    name.
  • Names are checked where they are used: a malformed name, an unknown or
    repeated feature, an unknown feature version, or a feature that does not
    support the base protocol or its version raises ValueError.
  • lf.query records the normalized name (python -> python:2.0, as before)
    and now also passes it to the LfQuery instance, which used to keep its
    class default 'python', so prompt and parse see the same name as the
    record. The autofix gate checks the parsed base
    (PromptingProtocol.SUPPORTS_AUTOFIX, True for python) instead of
    protocol.startswith('python:'); the result is the same for every existing
    protocol, except that a PythonPromptingProtocol subclass registered under
    another name now gets autofix too.
  • LfQuery.from_protocol parses the name, then looks up its base and version
    as before. _DEFAULT_PROTOCOL_VERSIONS is unchanged, so a protocol that
    registers its default version there (e.g. markdown) keeps working.
  • PromptingProtocol.from_name accepts versions and features (it rejected
    python:2.0), so every schema_repr, value_repr and parse_value call
    takes a recorded name. It still builds the protocol class without
    arguments, then sets the instance's version and features; name is the
    full name.
  • lf.parse dispatches on the base and also accepts names such as
    python:2.0 (it accepted exactly python or json); lf.score accepts
    them on both of its paths; lf.query_reward takes the protocol of the
    response.
  • Features are private for now (_ProtocolFeature): a feature declares its
    name, its version, whether that version is the default, its rank, and the
    base protocols and versions it supports. Registration rejects a second
    version of a feature unless exactly one of its versions is the default,
    versions of one feature with different ranks, and names or versions that are
    empty or contain : or +.

@google-cla

google-cla Bot commented Oct 29, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

…n])*`.

Precursor for protocol features such as `python+verbatim`, which is the next
change. This one registers no feature, so existing names (`python`,
`python:1.0`, `python:2.0`, `json`, `markdown`, ...) prompt, parse and are
recorded exactly as before.

WHAT
* One parser, `ProtocolName.parse` (schema/base.py), reads the grammar and
  normalizes a name: a feature without a version takes its default version,
  and features are ordered by rank, then by name, so the order does not depend
  on imports. Once the base version is filled in, a protocol has exactly one
  name.
* Names are checked where they are used: a malformed name, an unknown or
  repeated feature, an unknown feature version, or a feature that does not
  support the base protocol or its version raises `ValueError`.
* `lf.query` records the normalized name (`python` -> `python:2.0`, as before)
  and now also passes it to the `LfQuery` instance, which used to keep its
  class default `'python'`, so prompt and parse see the same name as the
  record. The autofix gate checks the parsed base
  (`PromptingProtocol.SUPPORTS_AUTOFIX`, True for `python`) instead of
  `protocol.startswith('python:')`; the result is the same for every existing
  protocol, except that a `PythonPromptingProtocol` subclass registered under
  another name now gets autofix too.
* `LfQuery.from_protocol` parses the name, then looks up its base and version
  as before. `_DEFAULT_PROTOCOL_VERSIONS` is unchanged, so a protocol that
  registers its default version there (e.g. `markdown`) keeps working.
* `PromptingProtocol.from_name` accepts versions and features (it rejected
  `python:2.0`), so every `schema_repr`, `value_repr` and `parse_value` call
  takes a recorded name. It still builds the protocol class without
  arguments, then sets the instance's `version` and `features`; `name` is the
  full name.
* `lf.parse` dispatches on the base and also accepts names such as
  `python:2.0` (it accepted exactly `python` or `json`); `lf.score` accepts
  them on both of its paths; `lf.query_reward` takes the protocol of the
  response.
* Features are private for now (`_ProtocolFeature`): a feature declares its
  name, its version, whether that version is the default, its rank, and the
  base protocols and versions it supports. Registration rejects a second
  version of a feature unless exactly one of its versions is the default,
  versions of one feature with different ranks, and names or versions that are
  empty or contain `:` or `+`.

PiperOrigin-RevId: 1010299788
@copybara-service
copybara-service Bot merged commit c191ca0 into main Oct 30, 2026
1 check failed
@copybara-service
copybara-service Bot deleted the test_1008606157 branch October 30, 2026 07:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants