On Fri, Jul 17, 2020, 12:10 David Mertz <me...@gnosis.cx> wrote: > On Fri, Jul 17, 2020, 8:16 AM Jonathan Fine <jfine2...@gmail.com> wrote: > >> Steve and I have different opinions, as to what the new behaviour of: >> >>> d = dict() >> >>> d[x=1, y=2] = 3 >> should be. >> >> He prefers that the assignment fail with >> TypeError: dict subscripting takes no keyword arguments >> >> I prefer that the assignment succeed (and hence a new key-value pair is >> added to 'd'). >> > > I definitely agree with Steven. It is obviously *possible* to create some > brand new type of object that is "multi-assignment fragment." But why?! > > No clearly useful semantics comes to mind for this new object. Well, it > would need to be hashable. Lots of things are though, so it's not like we > have nothing to use as dict keys now. > > We don't lose anything if we add the feature but intake don't support it > for dictionaries. If someone comes up with a really useful reason to have > that MultiAssignmentType, is not usually considered a breaking change to go > from "this raises am exception" to "this does something worthwhile" (but > obviously, in all such cases, you can artificially construct code that will > break without a certain exception). >
I think there are a few different options, with different advantages and disadvantages. Some have been touched on, but I don't think they are the only, or necessarily even best, options. I think it would be worthwhile looking at them all explicitly since I think they have different advantages and disadvantages: 1. Use keyword args. This has the advantage that it automatically handles putting things into a dict or limiting the potential keys, and will fail reliably if keyword indices aren't handled. But it has a bunch of issues. First, it is inconsistent with the existing indexing, which is a single tuple. Second, it only allows valid identifiers, which may be too limiting. Third, the position of positional and keyword indices are independent. 2. A single additional argument, containing a tuple of name/value tuples or a dict. This is consistent with the existing indexing, allows arbitrary identifiers, and will fail reliably if not handled. It still has the issue with positional and keyword indices having independent orders. 3. Use the existing tuple, but put keyword indices inside it as single-item dicts or named tuples. This has the advantage of keeping track of all the positions together, but you can already use these as indices so it has more potential for backwards compatibility issues. 4. Use the existing tuple, but put keyword indices in a new class. This keeps track of positions and doesn't have the same backwards compatibility issue, but would probably need either a new built-in or at least something in a stdlib module, and I am not sure where that would go. Care also needs to be made that it will fail properly in all cases where keyword indices aren't supported. 5. Use an entire new class for all indices when keyword indices are provided. This still requires a new class, and care has to be made to make sure it isn't accidentally handled improperly by existing classes. Overall I think option 2 is the best. It has pretty much no possibility of backwards-incompatibility, can handle the widest variety of values, and doesn't require any new classes or new behavior on the implementation side. >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EJSWZMAN3RVG4GAPQOKFTCX63BOU7DB4/ Code of Conduct: http://python.org/psf/codeofconduct/
