This is not my idea in the first place, and don't have much use for it.
mostly, I was pointing out that adding a couple of the set methods to the
Set ABC wouldn't be as disruptive as most additions of methods to ABCs.
That's it.
But to a couple points:
> Why do you want to add them? The point of
-Original Message-
From: Eryk Sun
Sent: 02 June 2020 02:02
To: python-ideas@python.org
Cc: Christopher Barker ; Steve Barnes
Subject: Re: [Python-ideas] Re: How to propose a change with tests where the
failing test case (current behaviour) is bad or dangerous
On 5/25/20, Christophe
On Fri, May 29, 2020 at 02:44:40PM -0400, tritium-l...@sdamon.com wrote:
> These are things that a runtime implementer has to decide on. These are
> also thing that a runtime use gets to complain about. "Don't share data
> amongst threads" is not advice to the cpython user to get truly parallel
Christopher Barker writes:
> TL; DR: In this particular case, I don't see much backward
> compatibility, so yes, let's add them.
> So it would not likely break much at all if they were added. (and
> I'm still confused why they aren't there in the firs place, the PEP
> doesn't seem very clear
On 5/25/20, Christopher Barker wrote:
> On Mon, May 25, 2020 at 10:59 AM Steve Barnes
> wrote:
>
>> On Windows
>> https://freetechtutors.com/create-virtual-hard-disk-using-diskpart-windows/
>> gives a nice description of creating a virtual disk with only operating
>> system commands. Note that it
TL; DR: In this particular case, I don't see much backward compatibility,
so yes, let's add them.
I've been thinking about the concept of adding methods (mixin or virtual)
to ABCs in the context of the "views on sequences" conversation recently on
this list.
In that context, we (or I, anyway :-)
On Mon, Jun 1, 2020 at 8:50 PM Brandt Bucher wrote:
> > These would be mixin methods, not abstract. Set already implements the
> various operators based on the abstract methods, it could easily add more
> mixin methods which would delegate to the operators. Classes which override
> the operators
> These would be mixin methods, not abstract. Set already implements the
> various operators based on the abstract methods, it could easily add more
> mixin methods which would delegate to the operators. Classes which override
> the operators with more efficient versions would automatically get
On Mon, Jun 1, 2020 at 5:31 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
>
> > 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 t
01.06.20 18:28, Raymond Hettinger пише:
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 th
> 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.
Currently the dictionary view objects behave exactly like sets when set
operations defined on them are used, such as the pipe or ampersand operators:
>>> d.keys() | [1]
{1, 2}
dictionary views are even sets by the ABC standard, having support for all the
required abstract methods:
>>> isinstance
12 matches
Mail list logo
