On Tue, Aug 4, 2020 at 10:54 AM Steven D'Aprano wrote:
> Yes, I remember the last time I played poker with some friends, and the
> dealer handed me the deck of cards and asked me to take a sample of 52
> cards *wink*
Most dealers want you to shuffle the deck *in place*. Although I'd be
highly
On Tue, Aug 4, 2020 at 3:35 AM Christopher Barker wrote:
>
> On Sat, Aug 1, 2020 at 6:10 PM Inada Naoki wrote:
>>
>> Repacking is mutation, and mutating dict while iterating it breaks the
>> iterator.
>> But `d.items()[42]` don't looks like mutation.
>
>
> Pardon my ignorance, but IS repacking
On Mon, Aug 3, 2020 at 5:50 PM Steven D'Aprano wrote:
> According to my testing in Python 3.8, the version with sample is about
> 10% slower than the "shuffled" helper I gave.
I got similar results, but my conclusion was that 10% isn’t significant:-)
Is it likely to be run in an inner loop?
On Mon, Aug 03, 2020 at 05:20:25PM -0400, Todd wrote:
> Another approach could be too simply pass the labelled indices in a dict as
> a third/fourth positional argument.
Why would we want to even consider a new approach to handling keyword
arguments which applies only to three dunder methods,
On Mon, Aug 03, 2020 at 05:51:58PM -0400, Ricky Teachey wrote:
> However I'll also point out that another idea from Jonathan Fine has the
> potential to fix both this problem and the key object signature problem,
> which is what he called a "SIGNATURE CHANGING ADAPTER".
>
>
> > Here's how it
On Mon, Aug 03, 2020 at 03:04:40AM -, raymond.hettin...@gmail.com wrote:
> Steven D'Aprano wrote:
> > > This is easily solved with a three-line helper:
> > def shuffled(iterable):
> ...
> > I have implemented this probably a half a dozen times, and I expect
> > others have too.
>
> FWIW,
On Mon, Aug 03, 2020 at 08:50:32AM -, raymond.hettin...@gmail.com wrote:
> Please also consider that we thought about all of this when sample()
> was first created. The current API is intentional. As you noted,
> this suggestion was also already rejected on the bug tracker. So,
> this
On Mon, Aug 3, 2020 at 2:35 PM Todd wrote:
> On Mon, Aug 3, 2020, 17:13 Guido van Rossum wrote:
>
>> On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker
>> wrote:
>>
>>>
>>> Yes, that would be correct. However, the function could instead be
defined as:
def __getitem__(self, index,
On Mon, Aug 3, 2020 at 5:23 PM Todd wrote:
> Another approach could be too simply pass the labelled indices in a dict
> as a third/fourth positional argument.
>
> So for indexing
>
> b = arr[1, 2, a=3, b=4]
>
> Instead of
>
> __getitem__(self, (1, 2), a=3, b=4)
>
> Just do
>
> __getitem__(self,
On Mon, Aug 3, 2020, 17:13 Guido van Rossum wrote:
> On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker
> wrote:
>
>>
>> Yes, that would be correct. However, the function could instead be
>>> defined as:
>>>
>>> def __getitem__(self, index, /, **kwargs):
>>> ...
>>>
>>> and then there'd be
Another approach could be too simply pass the labelled indices in a dict as
a third/fourth positional argument.
So for indexing
b = arr[1, 2, a=3, b=4]
Instead of
__getitem__(self, (1, 2), a=3, b=4)
Just do
__getitem__(self, (1, 2), {'a': 3, 'b': 4})
On Mon, Aug 3, 2020, 16:46 Christopher
On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker
wrote:
>
> Yes, that would be correct. However, the function could instead be defined
>> as:
>>
>> def __getitem__(self, index, /, **kwargs):
>> ...
>>
>> and then there'd be no conflict (as "self" and "index" must be passed
>> positionally).
> Yes, that would be correct. However, the function could instead be defined
> as:
>
> def __getitem__(self, index, /, **kwargs):
> ...
>
> and then there'd be no conflict (as "self" and "index" must be passed
> positionally). In effect, the naive spelling (which permits self and
> index to be
On Tue, Aug 4, 2020 at 4:38 AM Todd wrote:
>
> One potential issue with this approach just occurred to me. I apologise if
> my thinking on this is wrong.
>
> Say a project implements __getitem__ with the signature
>
> __getitem__(self, index, **kwargs)
>
> Doesn't that mean that a "index" will
One potential issue with this approach just occurred to me. I apologise if
my thinking on this is wrong.
Say a project implements __getitem__ with the signature
__getitem__(self, index, **kwargs)
Doesn't that mean that a "index" will not be an allowable index label, and
that this conflict will
On Sat, Aug 1, 2020 at 6:10 PM Inada Naoki wrote:
> Repacking is mutation, and mutating dict while iterating it breaks the
> iterator.
> But `d.items()[42]` don't looks like mutation.
>
Pardon my ignorance, but IS repacking a mutation? Clearly it's mutating the
internal state, but at the
On Sun, Aug 2, 2020 at 8:05 PM wrote:
> FWIW, we've already documented a clean way to do it,
> https://docs.python.org/3/library/random.html#random.shuffle , "To
> shuffle an immutable sequence and return a new shuffled list, use sample(x,
> k=len(x)) instead."
>
one downside of this is that it
Hi Todd
You wrote:
> Do we have an agreement on the API as Guido requested? From my
> understanding, and please correct me if I am wrong, you are still talking
> about implementing this using a new class. However, most people who
> support the use of labelled indexing.and expressed an opinion
I wasn't saying you had agreed to anything, I was saying you requested that
others agree on an API before trying to implement a prototype of it ("It
would help if someone looked into a prototype implementation as well (once
a design has been settled on).").
Jonathan seems to be going ahead with
On Mon, Aug 3, 2020 at 1:10 PM Jonathan Fine wrote:
> SUMMARY:
> Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.
>
> This package is about PEP 472 -- Support for indexing with keyword
> arguments
> See: https://www.python.org/dev/peps/pep-0472/
>
> As a result, I think
I haven't agreed to anything. Though last time I thought about this I was
in favor of Steven D'Aprano's idea of translating `x[1, 2, p=3, q=4]` into
`x.__getitem__((1, 2), p=3, q=4)`. What the dict class's `__getitem__`
would do with that is a different issue -- probably it would be an error.
On
On Mon, Aug 3, 2020, 13:11 Jonathan Fine wrote:
> SUMMARY:
> Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.
>
> This package is about PEP 472 -- Support for indexing with keyword
> arguments
> See: https://www.python.org/dev/peps/pep-0472/
>
> As a result, I think we're
As I said I would, I've now published a package on PyPI to support our
exploration and development of this idea.
You'll find more information on this new thread:
Subject: Package kwkey and PEP 472 -- Support for indexing with keyword
arguments
URL:
SUMMARY:
Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.
This package is about PEP 472 -- Support for indexing with keyword arguments
See: https://www.python.org/dev/peps/pep-0472/
As a result, I think we're now in a good position to try this idea out,
using present day
On Mon, Aug 3, 2020 at 8:26 AM Ram Rachum wrote:
> On Mon, Aug 3, 2020 at 3:20 PM wrote:
>
>> Ram Rachum wrote:.
>> > I notice that the random.sample function doesn't have a default behavior
>> > set when you don't specify k. This is fortunate, because we could make
>> > that behavior just
On Mon, Aug 3, 2020 at 3:20 PM wrote:
> Ram Rachum wrote:.
> > I notice that the random.sample function doesn't have a default behavior
> > set when you don't specify k. This is fortunate, because we could make
> > that behavior just automatically take the length of the first argument.
> So
> >
Ram Rachum wrote:.
> I notice that the random.sample function doesn't have a default behavior
> set when you don't specify k. This is fortunate, because we could make
> that behavior just automatically take the length of the first argument. So
> we could do this:
> shuffled_numbers =
On Mon, 3 Aug 2020 at 08:26, Dominik Vilsmeier wrote:
>
> On 02.08.20 15:36, Sebastian M. Ernst wrote:
>
> > Hi all,
> >
> > yet another (possibly bad?) idea from day-to-day work ...
> >
> > I occasionally need to import a lot of "stuff" from certain modules. The
> > "stuff" is usually following
On 02.08.20 15:36, Sebastian M. Ernst wrote:
Hi all,
yet another (possibly bad?) idea from day-to-day work ...
I occasionally need to import a lot of "stuff" from certain modules. The
"stuff" is usually following a pattern. E.g. I have modules that
(mostly) collect special exception classes
29 matches
Mail list logo
