[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Wed, Dec 1, 2021 at 6:18 AM Chris Angelico wrote: > > I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ > with some additional information about the reference implementation, > and some clarifications elsewhere. > > *PEP 671: Syntax for late-bound function argument defaults* > > Questions, for you all: > > 1) If this feature existed in Python 3.11 exactly as described, would > you use it? I would actively avoid using this feature and discourage people from using it because: > 2) Independently: Is the syntactic distinction between "=" and "=>" a > cognitive burden? I think that this imposes a significant cognitive burden, not for the simple cases, but when combined with the more advanced function definition syntax. I think this has the potential to make debugging large code-bases much harder. There is nothing that this proposal makes possible that is not already possible with more explicit code. ___ 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/3WSRN5NMENAPEUAYQPZCKUW2G43PNJM7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Sat, Sep 26, 2020 at 9:35 PM David Mertz wrote: > > On Sat, Sep 26, 2020 at 12:50 AM Stefano Borini > wrote: >> >> Other use cases are certainly allowed, but to me, something like >> >> a[1, 2, unit="meters"] >> a[1, 2, unit="meters"] = 3 >> >> makes me feel uncomfortable, although I might learn to accept it. >> >> Then why isn't the unit close to 3, as in >> >> a[1,2] = 3 * meters > > > I think this is a very natural looking use case, and is not as well addressed > by putting the multiplier outside the indexing. Imagine you have two arrays > that store lengths, but not necessarily in the same units. Whatever the > underlying representation, we would be able to ask, e.g.: > > a[1, 2, unit="furlongs"] == b[1, 2, unit="furlongs"] > > Sure, `a` might store its data as AUs and `b` might store its data as Plank > lengths. But the comparison like that would still work. More importantly, a > user wouldn't have to KNOW the underlying representation if she knew there > was a "unit" term. I don't find such examples a conclusive argument in favour of this syntax at all. Anything that stored a length and could do conversions in this way would presumably need to be some kind of length object that was able to handle conversions. In that case, the way that equality was calculated should take care of any conversions needed. I can't help feeling that this is a syntax looking for a set of solutions to apply itself to. It will add enormous complexity (together, no doubt, with speed issues and backwards-compatibility issues) to the language, and I'm not sure that I see the gain, yet. I'm obviously missing something. ___ 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/BMD5MWV6O2DE6IQ47VB4NMRJ7WTRB6FY/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
The curious thing about PEP 505 as far as I can see is that it introduces a new piece of syntax -- and for many people (to judge from the reactions here) a controversial piece of syntax -- to solve what seems to be a rather specific problem. The use-case that seems most discussed is unpacking information from nested JSON. One of the things that makes me really twitch about the examples like food = ham?.eggs?.spam?.chips is that I don't usually deal with deeply nested structures like that where it wouldn't matter to me which level of the nest returned a value. But let's leave that aside, because it seems to be an issue people face. For the specific case mentioned, what would be wrong with a utility function that looked something like: # Warning - typed on gmail before I've had my morning coffee and so not # at all tested, but I hope you can see what I mean. def nested_conditional_find(search_this, *args): this = search_this for term in args: new_this = getattr(search_this, term) if new_this is None: return this else: this = new_this then you could use this function as: food = nested_conditional_find(ham, 'eggs', 'spam', 'chips') One could even imagine adding extra tests along the way to a function like that, raising attribute errors if the wrong kind of data was encountered etc. What problem does PEP 505 add that can't be solved very nearly as elegantly by a utility function? PEP 505 doesn't seem to be about speed, only convenience. For that matter, for specific use cases, why couldn't objects be created where the attribute access functioned in just this kind of way? (not example code I'm willing to attempt before coffee ;-) ) Just a thought. I've carefully avoided words like 'pythonic', 'unpythonic', 'explicit', 'implicit', 'compact', 'bug-magnet' or 'perl'. Best wishes, N P.S. As an aside, in examples like food = spam?.eggs?.bacon -- if bacon is None then food is None, even if there were in fact eggs and spam. That thought tells me it must be breakfast time. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
On Mon, Jul 23, 2018 at 2:37 PM Mark E. Haase wrote: >> What does a scan through the existing core library say? > > > Please read the PEP before you shoot it down. It answers this _exact_ > question. My apologies. I'd missed the line where it says the examples were taken from the core library. So then a couple of points. Given the size of the core library, 678 seems like a very low number to me for a proposal like this -- but then I don't know quite what the threshold number would be for something like this. I guess I had expected that if None really were used in this way that there would be thousands of places where it might be used in the core libraries. Secondly (and I mean this with no animus at all), in some of the examples given I really struggle to see that the new version is more readable / maintainable / obvious than the old version. I can see the point in a couple of others. You'll say this is subjective as a test, and it is, I suppose. N. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
On Mon, Jul 23, 2018 at 8:08 AM Grégory Lielens wrote: > > > > On Monday, July 23, 2018 at 8:24:45 AM UTC+2, Nicholas Cole wrote: > >> And that leads to a simple question: how many times does this actually >> occur in real-world by python code? -- i.e. how many times do I want >> to check the value of an existing label, and, finding it is None (and >> None specifically), then assign it a value? > > > The PEP present a few examples. > > I think the compactness and clarity is really gained when doing a descent > into an "attribute tree", where any (or selected) members can be None, like > getting back to the example by Steven (spell-corrected, and expanded): > > meal = obj?.spam?.eggs.tomato?.cheese ?? "Mozzarella" > > Where, to put the proposal in even better light, I have assumed that eggs > instances always have a tomato attributes (i.e. are never None). > > This is indeed much more compact that the current version, and arguably more > readable (it's easier to parse once you know the syntax...but you have to > know the special syntax that will be used for this kind of stuff only). The > more you deepen the attribute access, the more you gain, but of course deep > attribute access is not so common. The new operators may make deep attribute > hierarchies (or deeply nested dicts/lists) slightly more common, and there > also I do not think it's a good thing. > That above example looks terrible to read (to me). Yes, that's a subjective statement. This example from the PEP is even worse: Example: if entry.is_dir(): dirs.append(name) if entries is not None: entries.append(entry) else: nondirs.append(name) After updating to use the ?. operator: if entry.is_dir(): dirs.append(name) entries?.append(entry) else: nondirs.append(name) In the first, it's totally clear to me when entries would be appended to and when it wouldn't. The second I had to read several times before I could see what was going on. The fact that it is already embedded in an if...else statement perhaps made it harder to understand. I guess people will say that we will just get used to the new syntax, but I don't see the benefit of making that particular "if" statement more compact, and leaving all the others in place. Or to put it another way, I'm just not convinced that "None" is sufficiently special. N. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
On Mon, Jul 23, 2018 at 2:38 AM Steven D'Aprano wrote: > > On Mon, Jul 23, 2018 at 12:59:20AM +0200, Giampaolo Rodola' wrote: > > > You're back at "since we have X that justifies the addition of Y" [1] > > and AFAICT that's the only argument you have provided so far in a 100+ > > messages discussion. > > The PEP itself justifies the addition of Y. This thread seems to be unnecessarily heated. Other languages have these operators, and so they aren't a wild idea. That said, from what I've seen, Swift optionals are very different things, and Python really has nothing like them. In Python, is None really special enough to need an operator like this? One issue for me is that the trivial case is already a one-liner: if a is None: a = 10 And it works for other things too: if a is -1: a = 10 if not a: a = 10 Again, is None special enough in Python to need this operator? I don't know. And that leads to a simple question: how many times does this actually occur in real-world by python code? -- i.e. how many times do I want to check the value of an existing label, and, finding it is None (and None specifically), then assign it a value? What does a scan through the existing core library say? I'm +0 on this proposal. Best wishes, N ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
