On Fri, Jun 14, 2019 at 12:39 PM Steven D'Aprano wrote:
> and no simple way to talk about *strict* subclass and superclass
> relationships without a verbose compound test:
>
> assert issubclass(parent, child) and child != parent
Well, why not go further then and make the following thing to be a
On Thu, May 16, 2019 at 10:41 AM Steven D'Aprano wrote:
> - try to assume the author of emails is writing in good faith
I have a piece of advice I often give to teams. When you catch
yourself in a conversation on a thought like "how can I convince an
opponent that I'm right" try first to think
On Tue, May 14, 2019 at 4:34 AM Steven D'Aprano wrote:
> You "see ... no obvious difference" between two functions that live in
> completely different modules?
>
>
>
> The bottom line is that it is completely normal and not uncommon for
> functions to be distinguished by the namespace they are
On Tue, May 14, 2019 at 6:19 AM Steven D'Aprano wrote:
> The problem is a lack of a symlink function that safely overwrites an
> existing file or symlink. We're just bike-shedding over its spelling
> and where it lives:
>
> - modify os.symlink and give it a "force" parameter
> - add a new
On Mon, May 13, 2019 at 9:24 PM Anders Hovmöller wrote:
> > On 13 May 2019, at 19:38, Steven D'Aprano wrote:
> >> On Mon, May 13, 2019 at 12:31:08PM +0200, Anders Hovmöller wrote:
> >> An optional "overwrite_if_exists=False" flag seems much nicer.
> >
> > Aside from the argument name being too
On Mon, May 13, 2019 at 4:44 AM Batuhan Taskaya wrote:
>
> Like repr and string the file system path is used alot and something like
> path!p might be handy.
>
> >>> class MyClass:
> ... def __fspath__(self):
> ... return "/home/batuhan"
> ...
> >>> assert f"{mc!p}" ==
On Wed, May 8, 2019 at 12:37 PM Chris Angelico wrote:
> When you come to write it up, I hope you can go into some detail about
> what you mean by "a third main object". Currently, the hierarchy is
> reentrant at the apex ("object" is an instance of "type", and "type"
> is a subclass of "object");
On Tue, May 7, 2019 at 2:45 AM Steven D'Aprano wrote:
>
> On Sun, May 05, 2019 at 04:23:58AM +0300, Serge Matveenko wrote:
>
> > So, I would like to propose adding a third main object called
> > `interface` in addition to `object` and `type` and to use it to define
On Sun, May 5, 2019 at 1:08 PM Luca Baldini wrote:
>
> Hi here,
> I wonder if the idea of adding to the statistics module a class to
> calculate the running statistics (average and standard deviation) of a
> generic input data stream has ever come up in the past.
>
> The basic idea is to do the
On Mon, May 6, 2019 at 7:48 PM Antoine Pitrou wrote:
>
> On Mon, 6 May 2019 19:39:39 +0300
> Serge Matveenko wrote:
> > With all respect, I disagree. There are ways to evolve Python such as
> > deprecation policies which proven to be effective. There are ways to
> &g
On Mon, May 6, 2019 at 7:29 PM Guido van Rossum wrote:
>
> On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka wrote:
>> I do not propose to change the current behavior. I propose to add new
>> named constructors. In most cases default constructors can be used, but
>> in cases when we use type
On Mon, May 6, 2019 at 5:33 PM Ivan Levkivskyi wrote:
>
> On Mon, 6 May 2019 at 03:23, Serge Matveenko wrote:
>>
>> On Sun, May 5, 2019 at 8:23 PM Stephen J. Turnbull
>> wrote:
>> >
>> > Serge Matveenko writes:
>> >
>> > >
On Sun, May 5, 2019 at 6:42 AM Steven D'Aprano wrote:
> It isn't that I *oppose* moving the checks to class-creation time
> instead of instantiation time, but I'd like to hear more about why it is
> a problem.
This doesn't look like moving checks from one place to another for me.
It is basically
> Another one is that ABCs aren't interfaces at all as they all to have
> actual implementations being encapsulated in them. This causes
> misunderstandings of the code and strange behaviors like in
> `collection.abc` module for instance where there is a lot of
> implementation and some methods
On Sun, May 5, 2019 at 6:42 AM Steven D'Aprano wrote:
>
> On Sun, May 05, 2019 at 04:23:58AM +0300, Serge Matveenko wrote:
> > So, I would like to propose adding a third main object called
> > `interface` in addition to `object` and `type` and to use it to define
>
On Sun, May 5, 2019 at 6:40 AM Ryan Gonzalez wrote:
>
> Worth maybe noting that this could play interestingly with PEP 484?
You're right. It already plays along with type hints in different
ways. At the moment it requires an exact match of implementation
method signatures with the interface
Hi, all!
I believe, almost everybody is familiar with the `abc` package.
The problem is that the ABC class is not a separate thing from
`object`. So, using ABCs often results in complicated inheritance
designs and even in the infamous metaclass conflict.
Another problem is that ABC performs
17 matches
Mail list logo
