We can add .keys() to Mapping to distinguish Mapping and Sequence.
But it is breaking change, of course. We shouldn’t change it.
We could use the presence of .keys in the subclasses hook only after first
checking
explicit cases (i.e. actual subclass or has been registered). Yes this
would break co
My personal motivating example for PEP 637 was shorthand for protocols.
`x: Protocol[foo=int, bar=Callable[str, int]]` could say x has attribute
foo which is an int and method bar from str to int.
On Wed, Apr 21, 2021 at 4:23 PM Paul Bryan wrote:
> I agree, that's duck typing with a protocol,
Why make it more
complicated?
On Wed, Mar 31, 2021 at 6:05 PM Chris Angelico wrote:
> On Thu, Apr 1, 2021 at 11:54 AM Caleb Donovick
> wrote:
> >
> > > Here, `Child` will *not* match as a sequence, even though it probably
> should,
> >
> > Strong disagree, if
> Here, `Child` will *not* match as a sequence, even though it probably
should,
Strong disagree, if I explicitly set `__match_seq__` to `False` in
`Parent` I probably have a good reason for it and would absolutely expect
`Child` to not match as a sequence.
> - Raise at class definition time if i
What is the motivation for returning `None` on empty splits? I feel like
this creates an unnecessary asymmetry. I don't personally have a use
case for the this feature so I may be missing something but it seems like
it would force an annoying pattern:
```
try:
foo()
except ExceptionGroup as
s`, so why not? But I trust judgement,
if you think that creating an apparent inconsistency around when
`get_type_hints` will work and when it won't is not worth being able to
resolve a few extra cases it probably isn't.
- Caleb Donovick
On Wed, Feb 3, 2021 at 8:55 AM Guido van Rossum wrote:
typing.get_type_hints(f, localns=nonlocal_vars) == {'x': int}
```
I would just open a PR to have `get_type_hints` attempt to resolve closure
variables by default. However, this would require an update to PEP 563 and
I don't know what the protocol is there.
-
s to the NAME
constant issue. Pick one. (preferably the version that includes match
syntax and some strange new syntax for explicit constants because I super
want the match syntax).
Caleb Donovick
On Fri, Jul 31, 2020 at 12:40 AM Tobias Kohn wrote:
> Hi Caleb,
>
> I will only answer to t
ble then I could express this cleanly:
def update_point_3d(p: Point3d, pt):
match pt:
case (p.x=, p.y=):
pass
case Point2d(p.x=, p.y=):
pass
...
- Caleb Donovick
___
Python-Dev mailing list -- python-dev@python