On Sun, Dec 9, 2018 at 2:00 PM Alan Isaac <alan.is...@gmail.com> wrote:
> I believe this was proposed in the past to little enthusiasm, > with the response, "you're using a library; learn its functions". > Not only that, NumPy and the core libraries around it are the standard for numerical/statistical computing. If core Python devs want to replicate a small subset of that functionality in a new Python version like 3.6, it would be sensible for them to choose compatible names. I don't think there's any justification for us to bother our users based on new things that get added to the stdlib. > Nevertheless, given the addition of `choices` to the Python > random module in 3.6, it would be nice to have the *same name* > for parallel functionality in numpy.random. > > And given the redundancy of numpy.random.sample, it would be > nice to deprecate it with the intent to reintroduce > the name later, better aligned with Python's usage. > No, there is nothing wrong with the current API, so I'm -10 on deprecating it. Ralf > Obviously numpy.random.choice exists for both cases, > so this comment is not about functionality. > And I accept that some will think it is not about anything. > Perhaps it might be at least seen as being about this: > using the same function (`choice`) with a boolean argument > (`replace`) to switch between sampling strategies at least > appears to violate the proposal floated at times on this > list that called for two separate functions in apparently > similar cases. (I am not at all trying to claim that the > argument against flag parameters is definitive; I'm just > mentioning that this viewpoint has already been > promulgated on this list.) > > Cheers, Alan Isaac > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion