Unexpected keyword 'maxsplit', for call to method split(sep, maxsplit = None) of 'string'

[vam-google]

Description of the problem / feature request:

The maxsplit argument in string.split() method is a positional argument now, but it is still documented as split(sep, maxsplit = None).

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Call:

"a=b".split("=", maxsplit = 1) 

anywhere in Starlark code. It works for bazel 0.28.1 and below, but the following for bazel 1.0.0:

unexpected keyword 'maxsplit', for call to method split(sep, maxsplit = None) of 'string'`

The documentation is not updated and it is a breaking change for 1.0.0

[vam-google]

Ah, whatever, not worth the trouble, probably...

[jmillikin-stripe]

This is breaking the Kubernetes build (at https://github.com/kubernetes/kubernetes/blob/v1.16.2/build/code_generation.bzl#L44):

return go_prefix + "/" + pkg.replace("staging/src/", "vendor/", maxsplit = 1)

cc @dslomov (release shepherd of v1.0)

[jin]

@laurentlb

[meisterT]

I assume #8147 is related cc @c-parsons

[laurentlb]

fyi @alandonovan
"a=b".split("=", maxsplit = 1) is allowed in Python 3 and rejected in Python 2.

I think maxsplit was marked as positional-only in Bazel by accident.

[gregestren]

What's the right priority for this?

[alandonovan]

I think this is the resolution of #8147 working as intended.

As with Python, nearly all parameters of Starlark built-in functions are positional only; the documentation promises to be explicit in every case where named arguments are permitted, but falls slightly short. The true list is: int(x, base), fail(sep), min(key), max(key), sorted(key, reverse). I'm not sure why Python3 decided to permit split(maxsplit) to be named where Python2 rejected it---perhaps passing a second separator string for maxsplit was a frequent mistake? (Conversely, Python2 accepts int(x=1) but Python3 rejects it.) I don't think it's worth adding maxsplit back.

See also go.starlark.net: google/starlark-go#292

[alandonovan]

Let's re-open this as a documentation issue.

The task is to ensure that the starlark spec makes plain that all core builtins reject named arguments, except for the following: int(x, base), fail(sep), min(key), max(key), sorted(key, reverse).