-
Notifications
You must be signed in to change notification settings - Fork 52
Arguments need not be strictly positional or keyword-only for creation and manipulation functions #85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
arange is tricky because arange(n) with a single argument should apply to the stop ( |
A primary argument for the current conventions is consistency, which underpins one of the stated goals of the consortium. By adopting consistent conventions across all defined interfaces we reduce the cognitive overhead required by readers, users, and developers to recall which interfaces support positional-only, keyword-only, and positional or keyword arguments. Furthermore, by enforcing a singular approach to providing arguments, optional or otherwise, we ensure uniformity of downstream consumption. If certain functions abide by different rules, unless a consumer is intimately familiar with either the classification of an interface (element-wise, linalg, creation/manipulation, etc), a consumer would not know a priori whether an interface ought to support one convention over the other. A one-true-way approach avoids this overhead, which I'd prioritize over saving keystrokes or permitting increased flexibility. Lastly, not clear how we'd define "true" options from "untrue" options. In short, the current conventions follow the dictum that, if an argument need not be required, either because of defaults or because providing such an argument results in secondary behavior (e.g., specialized use case), then an argument is optional and is thus keyword-only. |
I agree too this needs another look, to make sure we don't forbid writing clear code (e.g. using
That should be either left as is or changed to I actually think writing
Making all
I think consistency is important, but not the only concern - in cases where we break the most common or clearest way of writing code right now, we should fix that. |
Addresses comments in data-apisgh-85 and data-apisgh-107
Addresses comments in data-apisgh-85 and data-apisgh-107
Addresses comments in data-apisgh-85 and data-apisgh-107
Addresses comments in data-apisgh-85 and data-apisgh-107
Address comment in data-apisgh-85
Addresses comments in data-apisgh-85 and data-apisgh-107
Addresses comments in data-apisgh-85 and data-apisgh-107
Addresses comments in data-apisgh-85 and data-apisgh-107
Addresses comments in data-apisgh-85 and data-apisgh-107
Address comment in data-apisgh-85
* Update specification for arange Addresses comments in gh-85 and gh-107 * Update the specification for `full` and `full_like` Addresses comments in gh-85 and gh-107 * Update specification for `linspace` Addresses comments in gh-85 and gh-107 * Update specification for `empty`, `ones`, `zeros` Addresses comments in gh-85 and gh-107 * Update specification for `eye` This is useful/needed because `M` is not a descriptive name and that name does not match between different array libraries. * Update specification for `expand_dims`, `roll` and `reshape` Address comment in gh-85 * One more change to `eye`, more descriptive positional arguments * Address the default integer dtype issue for 32/64-bit Python Closes gh-151 * Update signature of `broadcast_to` Address a review comment; makes it consistent with other functions using `shape`.
It makes sense to require positional only arguments for functions like
add()
where there are no meaningful names, and likewise to require keyword arguments for true options.However, this is less useful for most creation and manipulation functions. For example,
arange
currently has the signaturearange(start, /, *, stop=None, step=1, dtype=None)
, but readable code could pass bothstart
andstop
as either positional or keyword arguments, e.g.,np.arange(start, stop)
andnp.arange(start=0, stop=10)
.I would suggest revisiting all of these functions and allowing arguments to be positional and keyword based when appropriate. Here are my suggestions off-hand:
arange(start, /, *, stop=None, step=1, dtype=None)
->arange(start, stop=None, *, step=1, dtype=None)
empty(shape, /, *, dtype=None)
->empty(shape, dtype=None)
full(shape, fill_value, /, *, dtype=None)
->full(shape, fill_value, *, dtype=None)
linspace(start, stop, num, /, *, dtype=None, endpoint=True)
->linspace(start, stop, num, *, dtype=None, endpoint=True)
ones
andzeros
should matchempty
expand_dims(x, axis, /)
->expand_dims(x, /, axis)
or evenexpand_dims(x, /, *, axis)
to match other manipulation functionsreshape(x, shape, /)
->reshape(x, /, shape)
roll(x, shift, /, *, axis=None)
->roll(x, /, shift, *, axis=None)
The text was updated successfully, but these errors were encountered: