[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 2020-08-27 12:33 a.m., Ricky Teachey wrote: On Wed, Aug 26, 2020 at 10:34 PM Steven D'Aprano > wrote: On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote: > It creates a language supported way for the creator of the class to decide > how t

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Thu, Aug 27, 2020, 00:56 Bruce Leban wrote: > A bunch of the conversation here is how to handle both positional and > keyword arguments with a single signature. Let me suggest an alternative. > At compile time, we know if the call is made with keyword arguments or not. > > a[1] positio

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

A bunch of the conversation here is how to handle both positional and keyword arguments with a single signature. Let me suggest an alternative. At compile time, we know if the call is made with keyword arguments or not. a[1] positional only a[b=1] keyword only a[1, b=1]both a[**k

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

> > ONE way might be to have the new method call the existing dunders. But > that's not my preference-- I would like to find another way. I do have > another idea, and I presented it in a previous response. Here it is again: > > def __key_or_index_translator__(self, pos1, pos2, *, x) -> > Tuple[Tup

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 10:34 PM Steven D'Aprano wrote: > On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote: > > It creates a language supported way for the creator of the class to > decide > > how to interpret the contents inside a subscript operation. > > We already have that: `__ge

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Thu, Aug 27, 2020 at 03:28:07AM +1200, Greg Ewing wrote: > On 27/08/20 12:53 am, Steven D'Aprano wrote: > > >Presumably the below method is provided by `object`. If not, what > >provides it? > > > >> def __getindex__(self, *args, **kwds): > >> if kwds: > >> raise TypeErr

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 4:01 PM Christopher Barker wrote: > Yes, it's slightly funny that square brackets convert to `index` rather >> than `*index`, but that ship sailed very long ago, and it's no big deal. >> There's no problem that needs solving and no need for code churn. >> > TL;DR -- let's

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote: > On Wed, Aug 26, 2020 at 11:19 AM Steven D'Aprano > wrote: > > > On Wed, Aug 26, 2020 at 10:10:34AM -0400, Ricky Teachey wrote: > > > > > But I have to say that I think this latest is a fantastic idea, and when > > > Jonathan present

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 11:03:20PM +0100, Stefano Borini wrote: > On Wed, 26 Aug 2020 at 17:50, David Mertz wrote: > > > > In my mind, *anything* other than the straightforward and obvious > > signature `__getitem__(self, index, **kws)` is a pointless > > distraction. > > It isn't. > and the re

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 9:39 PM Greg Ewing wrote: > If we use a new set of dunders, the signature of the one for > setting could be > > def __setindex__(self, value, *args, **kwds) > > which is not completely unsurprising, but plays better with > an arbitrary number of positional indexes. >

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 10:53 am, Todd wrote: On Wed, Aug 26, 2020, 18:04 Stefano Borini > wrote: On Wed, 26 Aug 2020 at 17:50, David Mertz mailto:me...@gnosis.cx>> wrote: you want this acquired_data[time, detector] to be allowed to be written as acqui

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 8:00 am, Christopher Barker wrote: Translating to: thing.__setitem__(self, (ind1, ind2), value, kwd1=v1, kw2=v2) which is pretty darn weird If we use a new set of dunders, the signature of the one for setting could be def __setindex__(self, value, *args, **kwds) which is not

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On 27/08/20 4:32 am, Ricky Teachey wrote: class Q:     def __subscript__(self, method_name, *args, **kwargs):          return getattr(self, method_name)(*args, **kwargs)     def __getitem__(self, *args, **kwargs): ...     # Note that I have made the RHS value the first argument in __setitem_

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 7:11 PM Stefano Borini wrote: > On Wed, 26 Aug 2020 at 23:56, Todd wrote: > > Again, implicit on your argument here is the assumption that all keyword > indices necessarily map into positional indices. This may be the case with > the use-case you had in mind. But for ot

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Wed, Aug 26, 2020 at 9:00 PM Greg Ewing wrote: > On 27/08/20 3:51 am, Ricky Teachey wrote: > > On Wed, Aug 26, 2020 at 11:30 AM Greg Ewing > > wrote: > > > > No, it would be done by checking type slots, no MRO search involved. > > > > Can you elaborate

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 11:06:26AM -0400, Ricky Teachey wrote: > Well I did give a couple examples: language supported opt-in for > pep-472-ification, and pep-472 opt-out. But Ok, more are needed. That's one example, not a couple: the ability to choose whether to opt-in or opt-out of keyword sub

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 3:51 am, Ricky Teachey wrote: On Wed, Aug 26, 2020 at 11:30 AM Greg Ewing > wrote: No, it would be done by checking type slots, no MRO search involved. Can you elaborate on this for my understanding? For frequently-used special methods such

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Thu, Aug 27, 2020 at 8:20 AM Stefano Borini wrote: > > Personally I think Jonathan and I (and possibly a couple others) > should form a separate subgroup and come up with a sensible and > logical set of options in a proto-PEP. The topic has been discussed > and we have plenty of ideas and opini

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, 26 Aug 2020 at 23:56, Todd wrote: > Again, implicit on your argument here is the assumption that all keyword > indices necessarily map into positional indices. This may be the case with > the use-case you had in mind. But for other use-cases brought up so far that > assumption is fals

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

My suggestion to solve this would be to use a similar rule to the walrus operator; only allow slice literals within either `()` brackets or `[]` square brackets; thus `{a: b: c: d, x: y}` becomes illegal and would need to be `{(a:b): (c:d), x: y}` ___

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020, 18:04 Stefano Borini wrote: > On Wed, 26 Aug 2020 at 17:50, David Mertz wrote: > > > > In my mind, *anything* other than the straightforward and obvious > signature `__getitem__(self, index, **kws)` is a pointless distraction. > > It isn't. > and the reason why it isn't is

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

Personally I think Jonathan and I (and possibly a couple others) should form a separate subgroup and come up with a sensible and logical set of options in a proto-PEP. The topic has been discussed and we have plenty of ideas and opinions, and if we want to achieve something coherent we need to take

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, 26 Aug 2020 at 17:50, David Mertz wrote: > > In my mind, *anything* other than the straightforward and obvious signature > `__getitem__(self, index, **kws)` is a pointless distraction. It isn't. and the reason why it isn't is that it makes it much harder for the implementing code to deci

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

Oh thanks, I had no idea that existed. I wanted to experiment with Mapping and unions but it's not working. I couldn't find any existing issues about this. Should I be opening an issue? If not then there's no need to explain what I'm doing wrong. ``` $ cat test.py print({} | {}) $ ./python test.p

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

Use typing.AbstractSet for the ABC (there was an unfortunate naming conflict -- we have dict and Mapping, list and Sequence, but set and Set...) On Wed, Aug 26, 2020 at 2:16 PM Alex Hall wrote: > On Wed, Aug 26, 2020 at 10:10 PM Christopher Barker > wrote: > >> Honestly, I haven't delved into t

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 10:10 PM Christopher Barker wrote: > Honestly, I haven't delved into type checking much, so maybe I'm making > this up, but what if you write a function that is type hinted to take a > Mapping, and uses | or |=, and all the test code uses a built in dict, and > all seems t

[Python-ideas] Re: still more use for pathlib.Path ....

Many of the tempfile modules' classes and utils could maybe return Path instead of str. I'm not sure how disruptive that would be, but I would definitely welcome something that avoids having to wrap everything in Path. I think they might need to return a "StrPath" for compatibility, but IMHO only

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

I’m sorry, I just can’t teach you how static type checking works. Read the mypy docs, install it, and experiment. On Wed, Aug 26, 2020 at 13:10 Christopher Barker wrote: > On Wed, Aug 26, 2020 at 12:38 PM Alex Hall wrote: > >> >> This is why we have ABCs in the first place (and static checking)

[Python-ideas] Re: still more use for pathlib.Path ....

On Thu, Aug 20, 2020 at 9:08 PM Ethan Furman wrote: > > But for a while is was painful to use, 'cause there was som much code > > that still used strings for paths. That was made a lot better when we > > introduced the __fspath__ protocol, and then updated the standard > > library to use it (ever

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On Tue, Aug 25, 2020 at 12:58 AM Alex Hall wrote: > > I haven't tried it myself but https://github.com/Delgan/loguru looks > promising. > Thanks -- that DOES look nice, and is on PyPi and maintained -- I'll give a try! -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 12:38 PM Alex Hall wrote: > > This is why we have ABCs in the first place (and static checking). So that > you can't add it to Sequence is already a smell. If it's in the Mapping > protocol, why isn't it in the Sequence protocol? > > This is all just a general feature of A

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 9:46 AM David Mertz wrote: > In my mind, *anything* other than the straightforward and obvious > signature `__getitem__(self, index, **kws)` is a pointless distraction. > > ... > Yes, it's slightly funny that square brackets convert to `index` rather > than `*index`, but

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 7:56 PM Guido van Rossum wrote: > On Wed, Aug 26, 2020 at 10:45 AM Alex Hall wrote: > >> On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum >> wrote: >> >>> But for your convenience you are proposing a problematic change (see >>> posts by others). >>> >> >> I think we've e

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

On Wed, Aug 26, 2020 at 11:57 AM Guido van Rossum wrote: > IIUC Cython (even if they were to adopt annotations) is not meant to be a > strict subset of Python -- almost no Cython module is valid Python. > correct. rather, it is a strict superset -- any valid Python should be compilable with Cyth

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

On Wed, Aug 26, 2020 at 11:20 AM Christopher Barker wrote: > > > On Wed, Aug 26, 2020 at 9:02 AM Guido van Rossum > >> Mypy includes an experimental compiler from typed Python to C that >> actually does what the OP is looking for. >> >> https://github.com/python/mypy/tree/master/mypyc >> > > Ther

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

On Wed, Aug 26, 2020 at 9:02 AM Guido van Rossum > Mypy includes an experimental compiler from typed Python to C that > actually does what the OP is looking for. > > https://github.com/python/mypy/tree/master/mypyc > There is also Cython, which is almost exactly what the OP is looking for. (I’m

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 10:45 AM Alex Hall wrote: > On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum wrote: > >> But for your convenience you are proposing a problematic change (see >> posts by others). >> > > I think we've established it's problematic to add it to the Sequence ABC, > but in ter

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

I think this method would be useful for list itself (maybe tuple, but I care less about that). It certainly should not be part of the Sequence protocol. I have often programmed a pattern where I .append() elements to a list in a loop, and *expect* at least N things to make it in. In such case, ge

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum wrote: > But for your convenience you are proposing a problematic change (see posts > by others). > I think we've established it's problematic to add it to the Sequence ABC, but in terms of only adding it to specific sequences like lists, I don't

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

But for your convenience you are proposing a problematic change (see posts by others). Maybe I meant overgeneralization instead. On Wed, Aug 26, 2020 at 10:20 AM Alex Hall wrote: > On Wed, Aug 26, 2020 at 4:32 PM Guido van Rossum wrote: > >> FWIW I don’t think we should add a .get() method for

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 4:32 PM Guido van Rossum wrote: > FWIW I don’t think we should add a .get() method for Sequence or for list. > It reeks of hyper-correctness. > What do you mean by this? I want the method because it's useful and convenient, not because it's 'correct'. I don't think that l

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, 26 Aug 2020 12:46:18 -0400 David Mertz wrote: > In my mind, *anything* other than the straightforward and obvious signature > `__getitem__(self, index, **kws)` is a pointless distraction. Probably. However, one must define how it's exposed in C. Regards Antoine. __

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

In my mind, *anything* other than the straightforward and obvious signature `__getitem__(self, index, **kws)` is a pointless distraction. We don't need new custom objects to hold keywords. We don't need funny conditional logic about one versus multiple index objects. We don't need some other metho

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 11:19 AM Steven D'Aprano wrote: > On Wed, Aug 26, 2020 at 10:10:34AM -0400, Ricky Teachey wrote: > > > But I have to say that I think this latest is a fantastic idea, and when > > Jonathan presented it to me it was very surprising that I had not seen it > > presented by an

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

Yes. That's what I meant by "the mixins are part of the contract", sorry. On Wed, Aug 26, 2020 at 8:45 AM Greg Ewing wrote: > On 27/08/20 2:32 am, Guido van Rossum wrote: > > The mixins are part of the contract. You are free to override them, > > their implementation is just a helpful,default. >

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

On Wed, Aug 26, 2020 at 8:41 AM Ronald Oussoren via Python-ideas < python-ideas@python.org> wrote: > > On 26 Aug 2020, at 17:02, krishnans2...@gmail.com wrote: > > One suggestion I had for the next Python release is to add > type-implication support. Many developers have learned Python, but do not

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Wed, Aug 26, 2020 at 11:30 AM Greg Ewing wrote: > On 27/08/20 12:53 am, Steven D'Aprano wrote: > > > This is going to slow down the most common cases of subscripting: the > > interpreter has to follow the entire MRO to find `__getindex__` in > > object, which then dispatches to the `__getitem_

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On 27/08/20 2:32 am, Guido van Rossum wrote: The mixins are part of the contract. You are free to override them, their implementation is just a helpful,default. That doesn't really answer my question. To put it another way: If someone wanted to implement an object that obeys the mapping protoco

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

> On 26 Aug 2020, at 17:02, krishnans2...@gmail.com wrote: > > One suggestion I had for the next Python release is to add type-implication > support. Many developers have learned Python, but do not want to use it since > it is slow. An awesome way to fix this is to have optional type-implicati

[Python-ideas] Re: Type Implications in Python 4 (or 3.9)

Do you mean the type annotations that Python has had for about ten years? And the typing library that uses them to specify type hints to compilers and other tooling? https://docs.python.org/3/library/typing.html On Wed, Aug 26, 2020 at 11:07 AM wrote: > One suggestion I had for the next Python

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On 27/08/20 12:53 am, Steven D'Aprano wrote: Presumably the below method is provided by `object`. If not, what provides it? def __getindex__(self, *args, **kwds): if kwds: raise TypeError("Object does not support keyword indexes") if not args: r

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > If the "keyword arguments in __getitem__" feature is added, .get() is > purely redundant. (Of course this thread would then become "make > 'default' a standard keyword argument for mutable collecti

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 10:10:34AM -0400, Ricky Teachey wrote: > But I have to say that I think this latest is a fantastic idea, and when > Jonathan presented it to me it was very surprising that I had not seen it > presented by anyone else yet. I think it solves a ton of problems, Such as? > a

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 10:40 AM Paul Moore wrote: > On Wed, 26 Aug 2020 at 15:12, Ricky Teachey wrote: > > > Objection 1: Slowing Things Down > > > > The INTENDED EFFECT of the changes to internals will be as Jonathan Fine > described: every time a subscript operation occurs, this new dunder >

[Python-ideas] Type Implications in Python 4 (or 3.9)

One suggestion I had for the next Python release is to add type-implication support. Many developers have learned Python, but do not want to use it since it is slow. An awesome way to fix this is to have optional type-implications. For example, if you know for sure that variable x is an int, you

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

Alex Hall writes: > I can't see any reason not to add it to range, strings, bytes, > deque, array, etc. beyond implementation effort. I also think it's > fine to leave them out at first. If the "keyword arguments in __getitem__" feature is added, .get() is purely redundant. (Of course this th

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, 26 Aug 2020 at 15:12, Ricky Teachey wrote: > Objection 1: Slowing Things Down > > The INTENDED EFFECT of the changes to internals will be as Jonathan Fine > described: every time a subscript operation occurs, this new dunder attribute > gets investigated on the class, and if it is not p

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 10:10 AM Ricky Teachey wrote: > *Objection 1: Slowing Things Down* > ...for actual implementation... we could wrap the existing item dunder > methods automatically at class creation time only when the new dunder > attribute is present. If it is not present, nothing happens

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

The mixins are part of the contract. You are free to override them, their implementation is just a helpful,default. FWIW I don’t think we should add a .get() method for Sequence or for list. It reeks of hyper-correctness. On Wed, Aug 26, 2020 at 01:33 Alex Hall wrote: > On Wed, Aug 26, 2020 at

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Wed, Aug 26, 2020 at 9:48 AM Steven D'Aprano wrote: > Demonstration: > > > py> class Dynamic: > ... def __getitem__(self, arg): > ... print("original") > ... type(self).__getitem__ = lambda *args: > print("replaced") > ... > py> > py> x =

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 7:58 AM Chris Angelico wrote: > -1. We have already had way WAY too much debate about the alternative > ways to handle kwargs in subscripts, and quite frankly, I don't think > this is adding anything new to the discussion. Can we just stop > bikeshedding this already and l

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Tue, Aug 25, 2020 at 10:51:42PM -0400, Ricky Teachey wrote: > > The only way it could tell that would be to inspect *at runtime* the > > `__setitem__` method. And it would have to do this on every subscript > > call. Introspection is likely to be slow, possibly very slow. This would > > make su

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Wed, Aug 26, 2020 at 03:06:25PM +1200, Greg Ewing wrote: > On 26/08/20 1:59 pm, Steven D'Aprano wrote: > >Most existing uses of subscripts already don't fit that key:value > >mapping idea, starting with lists and tuples. > > Not sure what you mean by that. Lists and tuples aren't key:value map

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

Please don't hijack an existing PEP for an unrelated issue. PEP 472 is an existing PEP for "Support for indexing with keyword arguments". https://www.python.org/dev/peps/pep-0472/ If you want to write a competing PEP, see PEP 1 for the steps you must follow: https://www.python.org/dev/peps/pe

[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access

On Wed, Aug 26, 2020 at 9:44 PM Jonathan Fine wrote: > > PROPOSAL > I think it will help solve our problem, to give Z = type(z) a new dunder > attribute that either is used as the internal_get_function, or is used inside > a revised system-wide internal_get_function. > > That way, depending on t

[Python-ideas] PEP 472 - new dunder attribute, to influence item access

SUMMARY Sequences and mappings are both similar and different. Let's introduce and use a new dunder attribute, to give item access appropriate behaviour. This proposal is based on an earlier thread - see Acknowledgments for URL. INTRODUCTION In Python, there are two sorts of builtin objects that h

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 1:41 AM Steven D'Aprano wrote: > On Tue, Aug 25, 2020 at 10:22:20AM -0700, Christopher Barker wrote: > > > This one is easier than most because it's pretty much a do we or don't we > > question, with the spelling semantics, all pretty much already decided. > > Is it to be

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 1:47 AM Greg Ewing wrote: > As a point of interest, is get() considered an official part of the > mapping protocol, or just nice-to-have? > > The docs don't seem to be very clear about that. There used to be > some tables listing the methods making up the core sequence and

[Python-ideas] Consider allow functools.singledispatch to work with typing.Union?

Julia's burgeoning popularity has renewed my interest in dynamic dispatch. It seems to me that many methods that have been written as a giant switch on types can more clearly be written using dynamic dispatch. It was prettty exciting to see that Python already has single dispatch built in, an