> I am often driven to use, for example, itertools set(permutations(multiset,
> n))
Try the more-itertools package:
https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.distinct_permutations
from more_itertools import distinct_permutations
from collections import Cou
> I propose a method:
> ...
> returns a dictionary {arg: value} representing the cache.
> It wouldn't be the cache itself, just a shallow copy
> of the cache data
I recommend against going down this path.
It exposes (and potentially locks in) implementation details such as
how we distinguish po
> Have a look at PEP 463, which looks into this in some detail.
I wish this PEP had gained more traction. Sooner or later, everyone wants an
expression form of a try/except.
When it comes to expressing "in the event of this exception, I want this
default", exception expressions read much more
Based on experience with the decimal module, I think this would open a can of
worms. To match what decimal does, we would need a Context() object with
methods for dump, dumps, load, loads. There would need to be a thread-local or
contextvar instance accessed by getcontext and setcontext, and p
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 = random.sample(
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, we've already documented a clean way to do it,
https://docs.python.org/3/library/random.html#ra
> On Jun 1, 2020, at 3:32 AM, a...@yert.pink a...@yert.pink
> wrote:
>
> I propose that the `Set` ABC API should be augmented to contain all of the
> named methods. This would provide consistency in the collections, and enhance
> the duck typing capabilities of the `Set` abc.
Two thoughts.
> On May 3, 2020, at 6:19 PM, Steven D'Aprano wrote:
>
>>> `frozenset` and `set` make a counterexample:
>>>
>> frozenset({1}) == {1}
>>> True
>>>
>>
>> Nice catch! That's really interesting. Is there reasoning behind
>> `frozenset({1}) == {1}` but `[1] != (1,)`, or is it just an acciden
> On Apr 29, 2020, at 11:15 AM, Tom Forbes wrote:
>
> What exactly would the issue be with this:
>
> ```
> import functools
> from threading import Lock
>
> def once(func):
>sentinel = object()
>cache = sentinel
>lock = Lock()
>
>@functools.wraps(func)
>def _wrapper():
>
> On Apr 29, 2020, at 12:02 PM, Christopher Barker wrote:
>
> On Apr 29, 2020, at 08:33, Christopher Barker wrote:
> > I've wondered about Linked Lists for a while, but while there are many
> > versions on PyPi, I can't find one that seems to be mature and maintained.
> > Which seems to indic
> On Apr 26, 2020, at 7:03 AM, Tom Forbes wrote:
>
> I would like to suggest adding a simple “once” method to functools. As the
> name suggests, this would be a decorator that would call the decorated
> function, cache the result and return it with subsequent calls.
It seems like you would ge
> On Mar 15, 2019, at 6:49 PM, Chris Angelico wrote:
>
> On Sat, Mar 16, 2019 at 12:40 PM Raymond Hettinger
> wrote:
>> Also, it seems like the efficiency concerns were dismissed with hand-waving.
>> But usually, coping and updating aren't the desired behavior
> On Mar 15, 2019, at 12:28 PM, Rhodri James wrote:
>
> I suspect this is a bit personal; I had sufficiently evil lecturers in my
> university Algebra course that I still don't automatically take the
> commutativity of "+" over a particular group as a given :-) Nothing is
> obvious unless
> On Mar 15, 2019, at 10:51 AM, Guido van Rossum wrote:
>
> The general idea here is that once you've learned this simple notation,
> equations written using them are easier to *manipulate* than equations
> written using functional notation -- it is as if our brains grasp the
> operators usin
> On Mar 5, 2019, at 2:13 PM, Greg Ewing wrote:
>
> Rhodri James wrote:
>> I have to go and look in the documentation because I expect the union
>> operator to be '+'.
>
> Anyone raised on Pascal is likely to find + and * more
> natural. Pascal doesn't have bitwise operators, so it
> re-uses +
> On Mar 4, 2019, at 11:24 AM, Guido van Rossum wrote:
>
> * Regarding how often this is needed, we know that this is proposed and
> discussed at length every few years, so I think this will fill a real need.
I'm not sure that conclusion follows from the premise :-) Some ideas get
proposed
> On Mar 1, 2019, at 11:31 AM, Guido van Rossum wrote:
>
> There's a compromise solution for this possible. We already do this for
> Sequence and MutableSequence: Sequence does *not* define __add__, but
> MutableSequence *does* define __iadd__, and the default implementation just
> calls sel
> On Feb 22, 2019, at 1:10 PM, Greg Ewing wrote:
>> “Typesetters hundreds of years ago used less than 80 chars per line, so
>> that’s what we should do for Python code now” is a pretty weak argument.
>
> But that's not the entire argument -- the point it is that typesetters
> had the goal of
> On Feb 21, 2019, at 5:06 PM, Chris Barker via Python-ideas
> wrote:
>
>
> class Frabawidget:
> ...
> @wozzle.setter
> def (self, woozle):
> if not (self.min_woozle < woozle < self.max_woozle):
> raise ValueError(f"Expected woozle to be between
> {self.min_
On Feb 18, 2019, at 8:37 PM, Simon wrote:
>
> I'd like to propose an update to PEP8. Indeed, the 80 characters per line
> guideline is, I feel, outdated.
I concur. We now put expressions in f-strings and have assignment expressions
that easily spill over 80 characters if one uses all but the
> On Jul 18, 2018, at 10:43 AM, Steve Dower wrote:
>
> Possibly this is exactly the wrong time to propose the next big syntax
> change, since we currently have nobody to declare on it, but since we're
> likely to argue for a while anyway it probably can't hurt (and maybe this
> will become t
On Jun 29, 2018, at 5:32 PM, Abe Dillon wrote:
>
> Sure, but in Hettinger's own words "whenever you have a constructor war,
> everyone should get their wish". People that want a counting constructor have
> that,
> people that want the ability to initialize values don't have that.
Sorry Abe, bu
On May 9, 2018, at 7:39 AM, Facundo Batista wrote:
>
> This way, I could do:
>
authors = ["John", "Mary", "Estela"]
"Authors: {:, j}".format(authors)
> 'Authors: John, Mary, Estela'
>
...
>
> What do you think?
That is an inspired idea. I like it :-)
Raymond
__
> On May 6, 2018, at 6:00 AM, Steven D'Aprano wrote:
>
> On Thu, May 03, 2018 at 04:32:09PM +1000, Steven D'Aprano wrote:
>
>> Maybe I'm slow today, but I'm having trouble seeing how to write this as
>> a lambda.
>
> Yes, I was definitely having a "cannot brain, I have the dumb" day,
> becau
> On May 2, 2018, at 11:32 PM, Steven D'Aprano wrote:
>
> Intended by whom?
By me. I proposed itemgetter() in the first place. That rationale I gave
convinced Guido and python-dev to accept it. I then wrote the code, docs,
tests and have maintained it for over a decade. So, I have a prett
> On May 2, 2018, at 1:08 AM, Vincent Maillol wrote:
>
> Our PEP idea would be to purpose to add a global default value for
> itemgeet and attrgetter method.
My preference is to not grow that API further. It is creep well beyond its
intended uses. At some point, we're really better off just
> On Apr 16, 2018, at 5:43 PM, Tim Peters wrote:
>
> BTW, if _`Counter * scalar` is added, we should think more about
> oddball cases. While everyone knows what _they_ mean by "scalar",
> Python doesn't.
I've started working on an implementation and several choices arise:
1) Reject scalar wi
> On Apr 15, 2018, at 10:51 PM, Tim Peters wrote:
>
> I also have no problem with inplace operators. Or with adding
> `Counter /= scalar", for that matter.
But surely __rdiv__() would be over the top, harmonic means be damned ;-)
Raymond
___
P
> On Apr 15, 2018, at 10:07 PM, Tim Peters wrote:
>
> Adding Counter * integer doesn't bother me a bit, but the definition
> of what that should compute isn't obvious.
Any thoughts on Counter * float? A key use case for what is being proposed is:
c *= 1 / c.total
Raymond
> On Apr 15, 2018, at 9:04 PM, Peter Norvig wrote:
>
> it would be a bit weird and disorienting for the arithmetic operators to have
> two different signatures:
>
> +=
> -=
> *=
> /=
>
> Is it weird and disorienting to have:
>
> +=
> *=
Yes, there is a preceden
> On Apr 15, 2018, at 7:18 PM, Wes Turner wrote:
>
> And I'm done sharing non-pure-python solutions for this problem, I promise
Keep them coming :-)
Thanks for the research. It helps to remind ourselves that almost none of our
problems are new :-)
Raymond
__
> On Apr 15, 2018, at 5:44 PM, Peter Norvig wrote:
>
> If you think of a Counter as a multiset, then it should support __or__, not
> __add__, right?
FWIW, Counter is explicitly documented to support the four multiset-style
mathematical operations discussed in Knuth TAOCP Volume II section 4.
> On Apr 15, 2018, at 2:05 PM, Peter Norvig wrote:
>
> For most types that implement __add__, `x + x` is equal to `2 * x`.
>
> ...
>
>
> That is true for all numbers, list, tuple, str, timedelta, etc. -- but not
> for collections.Counter. I can add two Counters, but I can't multiply one b
> On Apr 8, 2018, at 6:43 PM, Tim Peters wrote:
>
>> My other common case for accumulate() is building cumulative
>> probability distributions from probability mass functions (see the
>> code for random.choice() for example, or typical code for a K-S test).
>
> So, a question: why wasn't iter
> On Apr 8, 2018, at 12:22 PM, Tim Peters wrote:
>
> [Guido]
>> Well if you can get Raymond to agree on that too I suppose you can go ahead.
>> Personally I'm -0 but I don't really write this kind of algorithmic code
>> enough to know what's useful.
>
> Actually, you do - but you don't _think_
> On Apr 6, 2018, at 9:06 PM, Tim Peters wrote:
>
>>
>>What is this code trying to accomplish?
>
> It's quite obviously trying to bias the reader against the proposal by
> presenting a senseless example ;-)
FWIW, the example was not from me. It was provided by the OP on the tracker.
> On Friday, April 6, 2018 at 8:14:30 AM UTC-7, Guido van Rossum wrote:
> On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor wrote:
>> So some more humble proposals would be:
>>
>> 1) An initializer to itertools.accumulate
>> functools.reduce already has an initializer, I can't see any controversy
37 matches
Mail list logo
