[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
Or maybe you are not listening to what I am saying. It would only take effect for arguments, which have default value. So. dict().__setitem__(key, NotGiven) type(NotGiven) Exception(NotGiven) getattr(NotGiven, name) Ok, maybe there are some crucial functions, which have argument defaults. But again, there is another solution then, implement efficient decorator in standard library, maybe as part of sentinels, maybe as part of your PEP, maybe separately. I never said that it isn’t hard to write low-level python code. I will do that when the time is right for me. And I am not claiming that it is possible. If you read my language, all of my doubts are clearly expressed. You just seem to read everything as black and white even when it is not so. However, such statements are in no way valid arguments in such discussion. If my idea is not optimal, not necessary, no-one needs it or any other valid responses, why it is not a good one - I can accept it. But commenting that “it makes no sense” without properly explaining to me why after giving it some thought - it’s not fair. Also, if you looked at things from a bit more positive perspective, maybe you could come up with some nice new ways how it could be done. Maybe not exactly what I am proposing, but some alternative, which would make it work. Most likely something much better than I am proposing. After all, I am trying to see how your PEP can be improved, because if it could be used in all cases, where None can be, then at least to me, it would be a no-brainer to use it instead and to adapt it as best practice. DG > On 23 Jul 2023, at 07:35, Chris Angelico wrote: > > On Sun, 23 Jul 2023 at 14:08, Dom Grigonis wrote: >> >> IT IS AN OBJECT. Never said otherwise. > > One that you can't do any of the operations I described. There is no > way to use it as an object. > >> `inspect.getcallargs` can seemingly be modified for such behaviour. I just >> wrote a decorator, which does what I proposed using `inspect` module for a >> chosen sentinel value. The issue is that it would be a bottleneck if used on >> any callable, which is continuously used. `inspect.getcallargs`, >> `signature`, `getfullargspec` are very expensive. >> >> If that can be done, theoretically it should be able to be done at lower >> level as well. After all, behaviour of it should be modelled after what is >> happening at the function call. >> > > Since you clearly are not listening to the discussion, I will leave > you with one final recommendation: Write some code. Don't just claim > that it's possible; write actual code that makes it happen. You will > discover exactly how hard it is. If I am wrong, you will be able to > PROVE that I am wrong, instead of merely claiming it. > > ChrisA > ___ > 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/TPY2JHOBXUQIRNRYUUBUX46Y3HS4GQVK/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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/RTXRKZWWTRPGYHQTIRNGB57RMRFGWDQR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sun, 23 Jul 2023 at 14:08, Dom Grigonis wrote: > > IT IS AN OBJECT. Never said otherwise. One that you can't do any of the operations I described. There is no way to use it as an object. > `inspect.getcallargs` can seemingly be modified for such behaviour. I just > wrote a decorator, which does what I proposed using `inspect` module for a > chosen sentinel value. The issue is that it would be a bottleneck if used on > any callable, which is continuously used. `inspect.getcallargs`, `signature`, > `getfullargspec` are very expensive. > > If that can be done, theoretically it should be able to be done at lower > level as well. After all, behaviour of it should be modelled after what is > happening at the function call. > Since you clearly are not listening to the discussion, I will leave you with one final recommendation: Write some code. Don't just claim that it's possible; write actual code that makes it happen. You will discover exactly how hard it is. If I am wrong, you will be able to PROVE that I am wrong, instead of merely claiming it. ChrisA ___ 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/TPY2JHOBXUQIRNRYUUBUX46Y3HS4GQVK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
IT IS AN OBJECT. Never said otherwise. `inspect.getcallargs` can seemingly be modified for such behaviour. I just wrote a decorator, which does what I proposed using `inspect` module for a chosen sentinel value. The issue is that it would be a bottleneck if used on any callable, which is continuously used. `inspect.getcallargs`, `signature`, `getfullargspec` are very expensive. If that can be done, theoretically it should be able to be done at lower level as well. After all, behaviour of it should be modelled after what is happening at the function call. > On 23 Jul 2023, at 06:58, Chris Angelico wrote: > > On Sun, 23 Jul 2023 at 12:20, Dom Grigonis wrote: >> >> >>> There is no way to have a value that isn't a value, in Python. The >>> concept doesn't make sense and would break all kinds of things. >>> (That's why, when a special function like __getitem__ has to be able >>> to return literally anything, it signals "nothing to return" by >>> raising an exception.) >> >> I accept that it might be difficult to implement. >> I see that it would break things at cpython. >> Will definitely break some of the stdlib. E.g. inspect stuff. >> It wouldn’t break any of the existing python code. >> So yes, might not be a minor change. >> >> Could it be done nicely and easily by someone with relevant experience? I >> don’t know. >> >> >> But I fail to see why it doesn’t make sense - that’s a strong statement. >> >> It would be a value, just a value that is treated with exception in this >> particular case. >> There is definitely code at that level - resolving args, kwargs, dealing >> with “/" and “*” in relation to arguments provided, etc. >> >> It would take effect only on keyword arguments with defaults, if so then >> fairly contained matter. >> It could be a default of a keyword argument itself, would have a type and >> everything as any other object. >> > > Okay. You now have an object that you can't do anything with, because > it can't be a function argument. So... > > Show me how you would put this value into a dictionary. > > Show me how you would find out the type of this value. > > Show me how you would refer to this in an exception. > > Show me how you would access an attribute of this object. > > Show me how you would do ANYTHING WHATSOEVER with this object. > > It does not make sense to have an object that isn't an object. And in > Python, every value *is* an object. > > ChrisA ___ 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/CFFEGHQNQRDA7EDS4ZJBWAWDPU64OYHH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sun, 23 Jul 2023 at 12:20, Dom Grigonis wrote: > > > > There is no way to have a value that isn't a value, in Python. The > > concept doesn't make sense and would break all kinds of things. > > (That's why, when a special function like __getitem__ has to be able > > to return literally anything, it signals "nothing to return" by > > raising an exception.) > > I accept that it might be difficult to implement. > I see that it would break things at cpython. > Will definitely break some of the stdlib. E.g. inspect stuff. > It wouldn’t break any of the existing python code. > So yes, might not be a minor change. > > Could it be done nicely and easily by someone with relevant experience? I > don’t know. > > > But I fail to see why it doesn’t make sense - that’s a strong statement. > > It would be a value, just a value that is treated with exception in this > particular case. > There is definitely code at that level - resolving args, kwargs, dealing with > “/" and “*” in relation to arguments provided, etc. > > It would take effect only on keyword arguments with defaults, if so then > fairly contained matter. > It could be a default of a keyword argument itself, would have a type and > everything as any other object. > Okay. You now have an object that you can't do anything with, because it can't be a function argument. So... Show me how you would put this value into a dictionary. Show me how you would find out the type of this value. Show me how you would refer to this in an exception. Show me how you would access an attribute of this object. Show me how you would do ANYTHING WHATSOEVER with this object. It does not make sense to have an object that isn't an object. And in Python, every value *is* an object. ChrisA ___ 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/AHM6KHYJRFPLY3QUWV6MNCZ33BWSNR3Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
> There is no way to have a value that isn't a value, in Python. The > concept doesn't make sense and would break all kinds of things. > (That's why, when a special function like __getitem__ has to be able > to return literally anything, it signals "nothing to return" by > raising an exception.) I accept that it might be difficult to implement. I see that it would break things at cpython. Will definitely break some of the stdlib. E.g. inspect stuff. It wouldn’t break any of the existing python code. So yes, might not be a minor change. Could it be done nicely and easily by someone with relevant experience? I don’t know. But I fail to see why it doesn’t make sense - that’s a strong statement. It would be a value, just a value that is treated with exception in this particular case. There is definitely code at that level - resolving args, kwargs, dealing with “/" and “*” in relation to arguments provided, etc. It would take effect only on keyword arguments with defaults, if so then fairly contained matter. It could be a default of a keyword argument itself, would have a type and everything as any other object. ___ 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/YN3QPKPCN2HSTARQNXXHXZWJTH3AA5RI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
On Sun, 23 Jul 2023 at 09:15, Dom Grigonis wrote: > This works ok: > > ``` > def foo(bar=None): > if bar is None: > bar = A() > > class A: > pass > ``` > > If PEP is aiming to replace the latter example, then it would be great if it > kept all of its advantages. I.e. not having to change the definition order in > the module, which could be preferred as it is for other reasons. > Well, yes, it would work, but I still wouldn't recommend it. This is confusing to read. But since the default would be evaluated at call time, it would behave exactly as you describe. > And also to come back to my previous notice that there is no way to enforce > the default in case of function chain with cascading arguments. You said it > is a known limitation. Is there no easy & sensible approach to not have it? > E.g.: > > a) Any object which has certain dunder attribute, which evaluates to True? > b) NotGiven sentinel value which does exactly that. > c) A special constant, which, if present, at lower level makes things behave > the same way as the argument wasn’t provided at all. Such constant could be > very useful outside the scope of this PEP as well. Could be a great place to > introduce such constant? And to me it seems it could be a well justified one, > given it actually is special and does not fall under umbrella of generic > sentinel values. > > It would be great if it was to retain all the benefits of the latter example. > Then (at least from my POV) this PEP would be an excellent addition, and I am > most likely be using it now if it existed. > There is no way to have a value that isn't a value, in Python. The concept doesn't make sense and would break all kinds of things. (That's why, when a special function like __getitem__ has to be able to return literally anything, it signals "nothing to return" by raising an exception.) The only way to not pass an argument in Python is to not pass it. That means, at best, something like *a or **kw, where the sequence/dict either has something or doesn't, depending on whether you want to pass the argument. None of this is changed by PEP 671 and I don't think there's a lot of point trying to, as it would only cause more problems elsewhere. ChrisA ___ 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/34HFL6N6FMEIEHB5A22BBBXBAUIXXUBP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!
1. Not if it is exactly as described in PEP. 2. No. 3. - 4. Couple of points here. One check and one orthogonal idea, which would make this PEP very attractive to me. I would definitely like use this functionality if both of below points were satisfied/achievable. If any of those weren't satisfied I might just default to current syntax as I like to have a default pattern, which I know is flexible enough to cover most if not all the cases that I encounter. Currently, I manage this particular area (which your PEP is concerned with) with `None` and `unittest.Sentinel` defaults and deal with them in function's body. A. Currently, if I write: ``` def foo(bar=A()): pass class A: pass ``` I get an error. That is why having `bar=None` is advantageous. This works ok: ``` def foo(bar=None): if bar is None: bar = A() class A: pass ``` If PEP is aiming to replace the latter example, then it would be great if it kept all of its advantages. I.e. not having to change the definition order in the module, which could be preferred as it is for other reasons. My best guess is that it works the same as the latter example, (given the expression can contain other arguments, which are not there yet) but just wanted to double check. B. And also to come back to my previous notice that there is no way to enforce the default in case of function chain with cascading arguments. You said it is a known limitation. Is there no easy & sensible approach to not have it? E.g.: a) Any object which has certain dunder attribute, which evaluates to True? b) NotGiven sentinel value which does exactly that. c) A special constant, which, if present, at lower level makes things behave the same way as the argument wasn’t provided at all. Such constant could be very useful outside the scope of this PEP as well. Could be a great place to introduce such constant? And to me it seems it could be a well justified one, given it actually is special and does not fall under umbrella of generic sentinel values. It would be great if it was to retain all the benefits of the latter example. Then (at least from my POV) this PEP would be an excellent addition, and I am most likely be using it now if it existed. Regards, DG ___ 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/7DCPF624EEATZ5IRCSCHDIXDTCT2WYB3/ Code of Conduct: http://python.org/psf/codeofconduct/
