Op zo 18 nov. 2018 om 11:14 schreef Joel Nothman :
> I think we're all agreed that this change would be a good thing.
>
> What we're not agreed on is how much risk we take by breaking legacy code
> that relied on argument order.
>
I think that, in principle, it could be possible to do this with
I think we're all agreed that this change would be a good thing.
What we're not agreed on is how much risk we take by breaking legacy code
that relied on argument order.
I'd argue that we've often already broken such code, and that at least now
it will break with a TypeError rather than silent
Also want to say that I really welcome this decision/change. Personally, as far
as I am aware, I've trying been using keyword arguments consistently for years,
except for cases where it is really obvious, like .fit(X_train, y_train), and I
believe that it really helped me regarding writing less
As an end-user, I would strongly support the idea of future enforcement of
keyword arguments for new parameters.
In my group, we hold a standard that we develop APIs where _all_ arguments
must be given by keyword (slightly pedantic style, but has shown to have
benefits).
Initialization/call-time
On Thu, Nov 15, 2018 at 08:59:08AM -0500, Andreas Mueller wrote:
> I could try to see if people use positional arguments and where. No promise on
> timeline though.
If someone, you or someone else, does that, it would be very useful.
> I think there is little harm in doing it for new parameters
On 11/15/18 6:35 AM, Joel Nothman wrote:
I think there are cases where the first few arguments would be better
to maintain as positional, but users would very rarely use more than
two, and we have long assumed keyword arguments in most cases, and
never received complaints when we have
I think there are cases where the first few arguments would be better to
maintain as positional, but users would very rarely use more than two, and
we have long assumed keyword arguments in most cases, and never received
complaints when we have inserted not at the end or deprecated in the middle.
I am really in favor of the general idea: it is much better to use named
arguments for everybody (for readability, and to be less depend on
parameter ordering).
However, I would maintain that we need to move slowly with backward
compatibility: changing in a backward-incompatible way a library
We could just announce that we will be making this a syntactic constraint
from version X and make the change wholesale then. It would be less formal
backwards compatibility than we usually hold by, but we already are loose
with parameter ordering when adding new ones.
It would be great if after
On 11/14/18 8:36 PM, Hanmin Qin wrote:
I agree that this feature is advantageous and I'm +1 to apply it to
new classes/functions, but for existing classes/functions, does it
seem strange that only certain arguments are keyword only (i.e., some
arguments can be specified by position, while
I agree that this feature is advantageous and I'm +1 to apply it to new
classes/functions, but for existing classes/functions, does it seem strange
that only certain arguments are keyword only (i.e., some arguments can be
specified by position, while others can't)?
Hanmin Qin
- Original
11 matches
Mail list logo
