On 8 September 2016 at 15:05, Danilo J. S. Bellini
wrote:
>> 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/danilobellini/6384872
I'm not t
> So, why can't you call random.shuffle(all_tests) if you want to run your tests
in random order?
I dont randomize test order. People should stop assuming that they know
better. I need to randomize some arguments for one particular test and I
cannot call shuffle between tests. Its a continous list
On Thu, Sep 8, 2016 at 8:00 AM, Paul Moore wrote:
>
>> Type annotations are code, not tests.
>
> Not in Python they aren't.
>
The interpreter certainly thinks they're code rather than comments or
docstrings, even before PEP 526. I type this into my Python 3.4
interpreter:
>>> def foo(x:itn):
>>>
>
> That wont work because I would have to type the expression that is used as
> argument twice in a test.
(lambda data: random.sample(data, len(data)))(container)
That lambda is actually your "shuffled"...
2016-09-08 6:34 GMT-03:00 Arek Bulski :
> > So, why can't you call random.shuffle(all_te
On 8 September 2016 at 19:46, Hugh Fisher wrote:
> On Thu, Sep 8, 2016 at 8:00 AM, Paul Moore wrote:
>>
>>> Type annotations are code, not tests.
>>
>> Not in Python they aren't.
>
> The interpreter certainly thinks they're code rather than comments or
> docstrings, even before PEP 526. I type th
On 8 September 2016 at 10:34, Arek Bulski wrote:
> That wont work because I would have to type the expression that is used as
> argument twice in a test. I need shuffled. Enough said.
You've probably spent way more time debating shuffled here than you
would have needed to add a shuffled function
On 8 September 2016 at 10:46, Hugh Fisher wrote:
> Annotations look like code, they're mixed in with names and operators
> and literals and keywords, and all the standard syntax and semantic
> checks are applied.
Apologies - I was thinking you were referring to variable annotations
(and even ther
> On Sep 8, 2016, at 5:34 AM, Arek Bulski wrote:
>
> > So, why can't you call random.shuffle(all_tests) if you want to run your
> > tests in random order?
>
> I dont randomize test order. People should stop assuming that they know
> better.
That's the best I could do given the minimal explan
This thread is just going around and around in circles, so I will make
one final response and then I'm going to bow out.
On Thu, Sep 08, 2016 at 11:34:57AM +0200, Arek Bulski wrote:
> Needs to be shuffled().
>
> https://github.com/construct/construct/blob/master/tests/test_all.py
> See? No way
On Wed, Sep 7, 2016 at 12:20 PM, Serhiy Storchaka wrote:
> Before removing provisional state from the pathlib module, we should resolve
> the issue with Path.resolve(). It corresponds to os.path.realpath(), but
> behaves differently in case of non-existent path. Actually we can't say that
> any of
> You've probably spent way more time debating shuffled here than you would
have needed to add a shuffled function to your test file.
Another presupposition. I did add it to my utility. I am proposing to add
this to the std library so that others dont have to.
pozdrawiam,
Arkadiusz Bulski
___
On 8 September 2016 at 16:59, Arek Bulski wrote:
>> You've probably spent way more time debating shuffled here than you would
>> have needed to add a shuffled function to your test file.
>
> Another presupposition. I did add it to my utility. I am proposing to add
> this to the std library so that
I would prefer it if Path.resolve() resolved symlinks until it hits
something that doesn't exist and then just keep the rest of the path
unchanged. I think this is the equivalent of -m in the mentioned
utility (which I had never heard of).
It looks like os.path.realpath() already works this way.
[Arek Bulski ]
> I dont randomize test order. People should stop assuming that they know
> better.
They should, but, to be fair, you've left them little choice because
you've been so telegraphic about why you think this is a compelling
idea. Others are trying to fill in the blanks, and can only g
I also can't really get from "Arek has a need for this one line definition"
to "it should be in the standard library". Sure, 'shuffled()' is a more
obvious spelling than the slightly odd lambda. But I've yet to see the
reason that alias can't just be defined at the top of the test suite.
On Sep 8,
On Wed, Sep 07, 2016 at 07:28:30PM +1000, Hugh Fisher wrote:
> There's been discussion here and on python-dev regarding PEP 526 that
> assumes there will be multiple type checkers for Python. I really
> can't see this happening.
As Ryan has already pointed out, that has already happened.
> If ty
On Thu, Sep 08, 2016 at 07:46:41PM +1000, Hugh Fisher wrote:
> The interpreter certainly thinks they're code rather than comments or
> docstrings, even before PEP 526. I type this into my Python 3.4
> interpreter:
>
> >>> def foo(x:itn):
> >>> ... return x
>
> and the interpreter raises a NameEr
Hey, I just did put my thoughts on the discussion floor. Dont yell at me
for it not being the most interesting idea ever. There were few interesting
responses after all. Lets move on.
pozdrawiam,
Arkadiusz Bulski
___
Python-ideas mailing list
Python-id
On Thu, 8 Sep 2016 at 09:46 Guido van Rossum wrote:
> I would prefer it if Path.resolve() resolved symlinks until it hits
> something that doesn't exist and then just keep the rest of the path
> unchanged. I think this is the equivalent of -m in the mentioned
> utility (which I had never heard of
Arek Bulski wrote:
> I expected the **kw to reproduce the same order as actual keyword
> arguments. The only right way to solve it, as it seems to me, would be to
> make **kw an OrderedDict.
FYI: A change that keeps the order of **kw was just committed, so
3.6 will have that behavior:
https://ma
When thinking about the shuffled thread, it occurred to me that it was
quite easy to pass an iterable and expect the iterable to be shuffled.
but two mentioned implementation are close to success but fail by not
taking this use case in account:
def shuffled1(iterable):
result = iterable[:]
On Fri, Sep 9, 2016 at 9:36 AM, Xavier Combelle
wrote:
> and eventually this one work in all case of iterable
>
> def shuffled3(iterable):
> result = list(iterable)
> random.shuffle(result)
> return result
>
This is the one obvious way to do this. Not all iterables can
logically be sh
Hi all,
When starting CPython from the command line you can pass the -O option
to enable optimisations (eg `assert 0` won't raise an exception when
-O is passed). But, AFAIK, there is no way to change the optimisation
level after the interpreter has started up, ie there is no Python
function call
23 matches
Mail list logo
