On Sat, Mar 26, 2022, at 14:30, Brendan Barnwell wrote:
> To me it doesn't seem reasonable that someone would inherit from two
> classes and want to call a method from one without even knowing that
> there's a method name collision. If you're going to inherit from A and
> B, you need to k
Stephen J. Turnbull writes:
> I doubt that __as_parent__ solves the "arbitrarily deep"
problem (although you may be able to persuade me it will work
"better" "most of the time").
The way i've implemented it rn, it is possible :
__as_parent__ can take for argument any class in the inheritance tre
On Tue, 29 Mar 2022 at 04:24, malmiteria wrote:
> Essentially, when two parent class provide a method with the same name,
> that's what i call a conflict.
>
You keep saying this, but I'm still confused: how is that different
from the very normal behaviour of overriding a method? What makes one
o
Stephen J. Turnbull writes:
> Shouldn't A and B derive from Parenting? Or is it C that should?
Having Parenting anywhere in the inheritance tree would work with the current
implementation i have for it.
I intended it to be a root parent of any class without pre existing parent.
--
> How does
On Mon, Mar 28, 2022 at 11:13 AM Chris Angelico wrote:
> How do you distinguish conflicts from overrides?
>
I don't really get it either, but I think one of the points is that you
would get an error for any conflict, and then you could choose to
override if you wanted to -- rather than accidenta
Steven D'Aprano writes:
> How else are you going to get inheritance without a linear order? The
> interpreter can only call superclass methods one at a time, in
> some linear order.
You can decide what method should be the one resolved to *after* visiting all
superclass methods.
I've already
On Tue, 29 Mar 2022 at 06:12, malmiteria wrote:
>
> Steven D'Aprano writes:
>
> > How else are you going to get inheritance without a linear order? The
> > interpreter can only call superclass methods one at a time, in
> > some linear order.
>
> You can decide what method should be the one resolve
Hello everyone,
When I am coding in Python I often encounter situations where I have a
string like this one.
sample="""
fruit:apple
tree:[Apple tree]
quantity:{5}
quantity:{3}
"""
And I want to grab some kind of value from it.
So let me introduce you to the grab function. This is the definition
(I originally wrote this in bpo47147, but apparently because it has to
go through python-ideas first?)
I would like to be able to use a `yield from` expression in a `return`
statement without parentheses, as a small quality of life tweak, i.e.:
return yield from gen
instead of
return (yield
I'd like to be able to deconstruct `complex` objects into their real and
imaginary components using a `match` statement, like:
match 1-4j:
case complex(a, b):
print(f"{a=} {b=}")
This would just require setting
complex.__match_args__ = ("real", "imag")
The other bu
Chris Angelico writes:
> I'm not sure what you DO expect, though.
in this case :
```
class A:
def method(self): pass
class B:
def method(self): pass
class C(A,B): pass
```
it is unclear what C().method should resolve to. So instead of forcing a
resolution, i'd prefer an error to be raised
On Tue, 29 Mar 2022 at 07:39, malmiteria wrote:
>
> Chris Angelico writes:
> > I'm not sure what you DO expect, though.
>
> in this case :
> ```
> class A:
> def method(self): pass
>
> class B:
> def method(self): pass
>
> class C(A,B): pass
> ```
>
> it is unclear what C().method should resol
Some background: the reason we decided not to do this is because cases are
allowed to omit positional sub-patterns when matching. For example, it would be
possible to write this:
```
>>> match n:
... case complex(42j):
... ...
...
```
Read that carefully! It would match any complex
-1
Extra parentheses are not hard to type but this notation is much better
readable.
On Mon, Mar 28, 2022 at 11:06 PM Patrick Reader
wrote:
> (I originally wrote this in bpo47147, but apparently because it has to
> go through python-ideas first?)
>
> I would like to be able to use a `yield from`
On Mon, Mar 28, 2022 at 02:13:32PM +0200, StrikerOmega wrote:
> You can also "grab" values enclosed in brackets or in any kind of character
> and It works as you would expect.
>
> sample.grab(start="tree:[", end="]")
> >> 'Apple tree'
If we have
sample = "sqrt(sin(x) + cos(y))"
and sample.
On Mon, Mar 28, 2022 at 16:06 Patrick Reader
wrote:
> I would like to be able to use a `yield from` expression in a `return`
> statement without parentheses, as a small quality of life tweak, i.e.:
>
> return yield from gen
>
> instead of
>
> return (yield from gen)
What does this do? `return (
Finally got around to fleshing out my idea here.
My thought was to make an anonymous names tuple not as a new anonymous
class, but simply as an instance with specific field names. So all of these
would the the same class, but they would also be lightweight, and all
subclasses of tuple -- from a ty
On Sat, 26 Mar 2022 at 18:01, malmiteria wrote:
> Hi,
>
> Before anything, i made a github repository about this topic here :
> https://github.com/malmiteria/super-alternative-to-super
>
> The core of what i wanna discuss here is that i don't think mro and super
> (mainly because it relies on mro
On 29/03/2022 03:18, Michael Smith wrote:
On Mon, Mar 28, 2022 at 16:06 Patrick Reader
wrote:
I would like to be able to use a `yield from` expression in a
`return`
statement without parentheses, as a small quality of life tweak, i.e.:
return yield from gen
instead of
19 matches
Mail list logo
