Re: [Python-ideas] Shuffled

2016-09-07 Thread Danilo J. S. Bellini
> > 1. The cognitive leap between shuffling and sampling isn't small > I don't think so, actually the Fisher-Yates shuffle algorithm algorithm is an iterative sampling algorithm: https://gist.github.com/danilo bellini/6384872 > 2. "shuffled" would be a more logical name for an out-of-place

Re: [Python-ideas] Shuffled

2016-09-07 Thread Nick Coghlan
On 8 September 2016 at 13:33, Danilo J. S. Bellini wrote: > Nice to know about random.sample! =) > > I think what OP said can then be reduced to having the default k in > random.sample to be the iterable size. The existance of random.sample is a > very strong argument

Re: [Python-ideas] Shuffled

2016-09-07 Thread Steven D'Aprano
On Wed, Sep 07, 2016 at 11:47:49PM -0300, Danilo J. S. Bellini wrote: > Though I agree with the argument that inexperienced developers are > [usually] worse, that's not the case here, unless anyone here is really > trying to say the ones arguing for or against "shuffled" are inexperienced. > These

Re: [Python-ideas] Shuffled

2016-09-07 Thread Nick Coghlan
On 8 September 2016 at 12:00, Steven D'Aprano wrote: > On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote: > >> BUT experienced devs also need to recognize and respect the fact that >> younger/unexperienced developers are just better in detecting >> inconsistencies

Re: [Python-ideas] Shuffled

2016-09-07 Thread Steven D'Aprano
On Thu, Sep 08, 2016 at 12:22:28AM +0200, Sven R. Kunze wrote: > About the confusion of returning None. It's not confusing in the sense > of "o my god, I did it wrong, I need to learn it", but more, like "I > used shuffle, BECAUSE it's the only one I could find in a hurry" Then don't be in

Re: [Python-ideas] Typecheckers: there can be only one

2016-09-07 Thread Nick Coghlan
On 8 September 2016 at 07:31, Hugh Fisher wrote: > On Wed, Sep 7, 2016 at 9:56 PM, Nick Coghlan wrote: >> >> Exactly - in a dynamic language like Python, running a typechecker is >> a form of testing, rather than a necessary part of getting the code to

Re: [Python-ideas] Shuffled

2016-09-07 Thread Steven D'Aprano
On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote: > BUT experienced devs also need to recognize and respect the fact that > younger/unexperienced developers are just better in detecting > inconsistencies and bloody work-arounds. That is not a fact. It is the opposite of a fact --

Re: [Python-ideas] Shuffled

2016-09-07 Thread Alexander Belopolsky
On Wed, Sep 7, 2016 at 9:12 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > On Wed, Sep 7, 2016 at 8:14 PM, Arek Bulski wrote: > > > > If you want to see the declarative tests, here it is. > >

Re: [Python-ideas] Shuffled

2016-09-07 Thread Alexander Belopolsky
On Wed, Sep 7, 2016 at 6:56 PM, Arek Bulski wrote: > In the project I maintain (construct) there are declarative testcases that > look like a long list of (func, args, excepted output, error type) tuples. > There is no way for me to call shuffle in there. Can you explain

Re: [Python-ideas] Shuffled

2016-09-07 Thread David Mertz
On Wed, Sep 7, 2016 at 3:10 PM, Sven R. Kunze wrote: > @David > Your idea of a PyPI package could almost work. However, in an interactive > python console, I expect as much batteries included as possible to make it > as quick as possible. And considering how simple such wrapper

Re: [Python-ideas] Shuffled

2016-09-07 Thread Arek Bulski
Thank you all for the meta discussion. I know we sidetracked a bit but please everyone remember, this is an open discussion floor. I can present you a use case, just didnt think I even needed one. This seems so obvious to me that it should just go in without much saying. In the project I maintain

Re: [Python-ideas] Shuffled

2016-09-07 Thread Matt Gilson
I lurk around here a lot more than I actually post -- But in this case I find myself weighing in firmly on the side of "please don't add this". It'd just add noise in the documentation and __builtins__ namespace. There are millions of useful functions that *could* be added to the `list` object

Re: [Python-ideas] Typecheckers: there can be only one

2016-09-07 Thread Sven R. Kunze
On 08.09.2016 00:00, Paul Moore wrote: On 7 September 2016 at 22:31, Hugh Fisher wrote: The average programmer such as myself will expect that if I write code specifying the type of a variable or whatever it should *do something*. It's code, I wrote it, it should be

Re: [Python-ideas] Typecheckers: there can be only one

2016-09-07 Thread Ivan Levkivskyi
On 8 September 2016 at 00:00, Paul Moore wrote: > > Type annotations are code, not tests. > > Not in Python they aren't. > Well, to a certain extent. One can try something like this in REPL: from typing import get_type_hints import __main__ s: str class C: x: int

Re: [Python-ideas] Shuffled

2016-09-07 Thread Sven R. Kunze
On 07.09.2016 02:49, Chris Kaynor wrote: I'll weigh in and say that I've had a few cases where I've wanted a shuffled function, but not many. The vast majority are interactive uses, where I want to get a sampling of data, and in those cases I'm normally just printing the output (often, by

Re: [Python-ideas] Shuffled

2016-09-07 Thread Tim Peters
[Sven R. Kunze ] > I am not questioning experience which everyone in a team can benefit from. > > > BUT experienced devs also need to recognize and respect the fact that > younger/unexperienced developers are just better in detecting > inconsistencies and bloody work-arounds. They

Re: [Python-ideas] Typecheckers: there can be only one

2016-09-07 Thread Paul Moore
On 7 September 2016 at 22:31, Hugh Fisher wrote: > The average programmer such as myself will expect that if I write code > specifying the type of a variable or whatever it should *do > something*. It's code, I wrote it, it should be interpreted. Reading the documentation

Re: [Python-ideas] Typecheckers: there can be only one

2016-09-07 Thread Hugh Fisher
On Wed, Sep 7, 2016 at 9:56 PM, Nick Coghlan wrote: > > Exactly - in a dynamic language like Python, running a typechecker is > a form of testing, rather than a necessary part of getting the code to > work in the first place. > The average programmer such as myself will

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

2016-09-07 Thread Nick Coghlan
On 8 Sep 2016 02:48, "Guido van Rossum" wrote: > > On Wed, Sep 7, 2016 at 9:34 AM, Yury Selivanov wrote: > > Thank you for accepting the PEP! Will focus on the implementation now. > > You're welcome! Good luck with the implementation. > > @Nick,

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

2016-09-07 Thread Yury Selivanov
On 2016-09-06 7:19 PM, Guido van Rossum wrote: On Tue, Sep 6, 2016 at 10:42 AM, Yury Selivanov wrote: On 2016-09-04 3:10 AM, Adam Bartoš wrote: will await be allowed also in the "if" part of comprehensions? And what about the "in" part? (e.g. if I'm not mistaken, we

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

2016-09-07 Thread Nick Coghlan
On 8 September 2016 at 00:57, Koos Zevenhoven wrote: > On Wed, Sep 7, 2016 at 3:27 PM, Nick Coghlan wrote: > [...] >> >> The new issue that's specific to comprehensions is that the statement >> form doesn't have the confounding factor of having an