>
> 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
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
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
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
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
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
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 --
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.
> >
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
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
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
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
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
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
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
[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
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
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
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,
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
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
21 matches
Mail list logo