[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10
On 2020-02-04, 01:00 GMT, Brett Cannon wrote: > I think people also forget that prior to worrying about > maintaining backwards-compatibility with Python 2 we > deprecated for a release and then we removed (so an 18 month > deprecation period). But then you mustn’t filter out deprecation warnings. And yes, we have to relearn that deprecation warning means the incoming doom, not something to ignore. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: [email protected] GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Thou shalt not nede to be afrayed for any bugges by night. -- Coverdale's 1535 translation of Psalm 91 (or Christopher Higley's 1972 thesis explaining why programmers' are nocturnal beasts) ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/JM6X6A4E5YEYSZWSVM5CMNDSUOAHJ2A5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
This is a great PEP. Just recently I needed this and was surprised that nothing of the sort had been implemented yet (I looked for quite some time). I have one suggestion: Wouldn't it be useful for these operators to also accept sets (functionally acting like a dict with None for all values)? This would make it very elegant to 'normalize' dicts by pruning (dict & set) or padding (set | dict) dictionaries. I would find this useful for efficient data sanitation purposes, as when processing input from web forms. Am 05.02.2020 02:28 schrieb Guido van Rossum: Thanks Brandt (and Steven of course)! If there are no objections by next week I'll recommend this to the Steering Council for acceptance. In the meantime, I am wondering about the reference implementation -- is it suitable to submit as a PR? Or is it a toy written in pure Python? (I found it a little tricky to follow your branch.) On Tue, Feb 4, 2020 at 4:57 PM Brandt Bucher wrote: Steven D'Aprano and I have pushed a third draft of PEP 584: https://www.python.org/dev/peps/pep-0584/ [1] The accompanying reference implementation is on GitHub: https://github.com/brandtbucher/cpython/tree/addiction [2] For those who have been following the discussions over the past year on python-ideas, this new draft does not contain much additional content; the most notable difference is that the choice of operator has been changed from + to |. The rest of the revisions are mostly reformatting and reorganizing the information to bring the document in line with PEP standards. Please let us know what you think – we'd love to hear any *new* feedback that hasn't yet been addressed in the PEP or the related discussions it links to! Thanks! Brandt ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ [3] Message archived at https://mail.python.org/archives/list/[email protected]/message/TTIKCDIPC2CDHX23Y57CPHDSVYOWCCER/ [4] Code of Conduct: http://python.org/psf/codeofconduct/ [5] -- --Guido van Rossum (python.org/~guido [6]) _Pronouns: he/him __(why is my pronoun here?)_ [7] Links: -- [1] https://www.python.org/dev/peps/pep-0584/ [2] https://github.com/brandtbucher/cpython/tree/addiction [3] https://mail.python.org/mailman3/lists/python-dev.python.org/ [4] https://mail.python.org/archives/list/[email protected]/message/TTIKCDIPC2CDHX23Y57CPHDSVYOWCCER/ [5] http://python.org/psf/codeofconduct/ [6] http://python.org/~guido [7] http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/NFVVGNXBSABWIPCDH6C3AQA65R37DFPJ/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CL2AKG47ZJJQXHUREHTD47VQZYJZNJLH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
On 05/02/2020 12:27, Musbur wrote: I have one suggestion: Wouldn't it be useful for these operators to also accept sets (functionally acting like a dict with None for all values)? This would make it very elegant to 'normalize' dicts by pruning (dict & set) or padding (set | dict) dictionaries. I would find this useful for efficient data sanitation purposes, as when processing input from web forms. Why None? Why not 0, or False, or 42? This sort of thing belongs more in a function or method, IMHO. On the original PEP, I'm resigned to it being the union operator and +1 on the whole thing. Good work, guys! -- Rhodri James *-* Kynesim Ltd ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/WUOEEIO3TDP6TOT2UWYEXVVQBEZ7XN2G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
> I have one suggestion: Wouldn't it be useful for these operators to also > accept sets (functionally acting like a dict with None for all values)? > Why None? Why not 0, or False, or 42? This sort of thing belongs more in a > function or method, IMHO. Well, in their defense, None is the null object in Python, so it would be a natural choice. With that said, I am strongly against this for several reasons: - The proposal in its current form is very easy to wrap your head around: "|" takes dicts, "|=" takes anything dict.update does. - Python doesn't allow sets to be dictionaries anywhere else. It's much more natural to use a dict like a set than to use a set like a dict. Hence, this PEP! - A consistent argument that we've gotten since the very beginning is something to the effect of "I don't know what types are being used in the expression 'a | b'." While we argue that this isn't the issue in practice that people make it out to be, accepting sets here would definitely muddy the waters. > This would make it very elegant to 'normalize' dicts by pruning (dict & set) > or padding (set | dict) dictionaries. Well, if the PEP lands, the padding part is easy: padded = dict.fromkeys(expected) | given Or even better, just do the dict.fromkeys construction at module level once, and do: padded = EXPECTED | given Or, implement the behavior in a subclass if you truly need it to be a set! We're intentionally very subclass-friendly (unlike list, for example). ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/G3NWWUFR3SJECCXIAUGHNEJLSCBQBEVG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
On Thu, Feb 6, 2020 at 3:47 AM Brandt Bucher wrote: > > > I have one suggestion: Wouldn't it be useful for these operators to also > > accept sets (functionally acting like a dict with None for all values)? > > > Why None? Why not 0, or False, or 42? This sort of thing belongs more in > > a function or method, IMHO. > > Well, in their defense, None is the null object in Python, so it would be a > natural choice. With that said, I am strongly against this for several > reasons: > > - The proposal in its current form is very easy to wrap your head around: "|" > takes dicts, "|=" takes anything dict.update does. > - Python doesn't allow sets to be dictionaries anywhere else. It's much more > natural to use a dict like a set than to use a set like a dict. Hence, this > PEP! > - A consistent argument that we've gotten since the very beginning is > something to the effect of "I don't know what types are being used in the > expression 'a | b'." While we argue that this isn't the issue in practice > that people make it out to be, accepting sets here would definitely muddy the > waters. > - and you can use dict.fromkeys to "upgrade" a set to a dict anyway. If this goes through as is, and then in a few years' time we start seeing lots of people begging to be able to skip the explicit fromkeys and accept sets directly, it can be addressed then. Personally, I think sets make good sense on the right hand side of an intersection (as a means of saying "whitelist the keys to this set"; values would be irrelevant there anyway), but not with union/update. ChrisA ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/NZWJDWAHGJSOMI23ZAU5CDEC4BHJMFRT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 584: Add Union Operators To dict
05.02.20 14:27, Musbur пише:
I have one suggestion: Wouldn't it be useful for these operators to also
accept sets (functionally acting like a dict with None for all values)?
This would make it very elegant to 'normalize' dicts by pruning (dict &
set) or padding (set | dict) dictionaries. I would find this useful for
efficient data sanitation purposes, as when processing input from web
forms.
d = {}
d |= {(1, 2)}
What is d now? {1: 2} or {(1, 2): None}
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/ZUXJBYUHXGAKLH3TOVB4UUXQUBFOQAIK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Clarification of unpacking semantics.
Commits 13bc139 and 8a4cd70 introduced subtle changes in the evaluation logic of unpacking operations. Previously, all elements were evaluated prior to being collected in a container. Now, these operations are interleaved. For example, the code `[*a, *b]` used to evaluate in the order `a` -> `b` -> `a.__iter__()` -> `b.__iter__()`. Now, it evaluates as `a` -> `a.__iter__()` -> `b` -> `b.__iter__()`. I believe this breaking semantic change is a bug, and I've opened a PR to fix it (https://github.com/python/cpython/pull/18264). My reasoning is that "unary *" isn't an operator; it doesn't appear on the operator precedence table in the docs, and you can't evaluate `*x`. Like the brackets and the comma, it's part of the syntax of the outer display expression, not the inner one. It specifies how the list should be built, so it should be evaluated last, as part of the list construction. And it has always been this way since PEP 448 (as far as I can tell). The docs themselves seem to support this line of reasoning (https://docs.python.org/3/reference/expressions.html#evaluation-order): > In the following lines, expressions will be evaluated in the arithmetic order > of their suffixes: > ... > expr1(expr2, expr3, *expr4, **expr5) Note that the stars are not part of expressions 1-5, but are a part of the top-level call expression that operates on them all. Mark Shannon disagrees with me (I'll let him reply rather than attempt to summarize his argument for him), but we figured it might be better to get more input here on exactly whether you all think the behavior should change or not. You can see the discussion on the PR itself for some additional points and context. Thanks! Brandt ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/4HS2ZEQWWFMQ7IO5ZHBNWEYLN4PIYDCD/ Code of Conduct: http://python.org/psf/codeofconduct/
