Hello, On Fri, 18 Dec 2020 03:05:02 +1300 Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> On 18/12/20 1:52 am, Paul Sokolovsky wrote: > > On Fri, 18 Dec 2020 01:23:34 +1300 > > Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > >> On 17/12/20 11:25 pm, Paul Sokolovsky wrote: > >>> a) (a.b)() syntax > >>> b) apply() being resurrected > >> > >> I can't answer that without knowing what alternative semantics > >> you have in mind for (a.b)(). You haven't really explained that > >> yet. > > > > But I did by now, and you didn't need to wait for me to do it, > > because "(a.b)()" does *exactly* what *you* or anybody else would > > think it does, based on your knowledge of what grouping parens in > > the expressions do. So again, "(a.b)()" first extracts a value of > > the "b" *attribute* from the object held in variable "a", then > > calls that value with 0 arguments. > > We're going round in circles. Yep :-(. I wonder, if reading of each other's arguments more thoroughly could help. > Are we talking about current > Python semantics, or proposed new semantics? Please just > give us a clear answer on that. I'm not talking about the current Python semantics, because there's nothing to talk about. We both agreed it won't change, so what do you want to talk about re: it? The only purpose "current Python semantics" serve in the discussion is that new semantics gets explained in terms of difference wrt to the current. Otherwise, I'm talking how the proposed new semantics comes out smoothly and naturally from the existing Python semantics, syntax, and other details. And feedback on the "comes out smoothly and naturally" part is exactly what I'm interested in. > If we're talking about current semantics, then my knowledge Right, so if the current semantics clouds your view, one approach would be to put it aside, and look at the things with unencumbered look, to see if you can see the things I'm talking about. > of what grouping parens do (which is based on what the > Python docs define them to do) means that a.b() and (a.b)() > are just different ways of writing *exactly* the same thing. > > > That's in striking difference to "a.b()", which calls the *method* > > "b" of object held in variable "a". > > No, it doesn't. It calls *whatever* object a.b returns. Bingo! That's exactly what I seek to improve, so it with much higher probability "returns" a *method*, and not just "whatever". > It only calls a method if b happens to be a method. > It might not be. It might be a callable object stored > in an instance attribute, or a function stored in a > module attribute, in which case the very same syntax is > just an ordinary call, not a method call. So, it seems like you have read what I wrote in the message https://mail.python.org/archives/list/python-ideas@python.org/message/PF42DP2IYYRFUJMYCJ2NDRBXU57VNFEH/ , because you explain how the current semantics work, after I explained how it's being changed to work differently. And if something is unclear in my explanation, just let me know. It's not like the message above is 2-line and leaves much for you to guess. It's not 30KB text either, which chews thru all aspects (like my previous proposal does). So, if some aspect *of new semantics* is unclear, I'd be glad to elaborate on it. (Ahead of a 30KB text, which is coming, but much later). > That last case is something you might want to ponder. > The same LOAD_METHOD/CALL_METHOD bytecode sequence is > being executed, yet it's *not* performing a method > call! How does your new improved theory of method calls > explain *that*? As any other such case - "as implementation artifact grounded in semantic ambiguities of a dynamic language". My aim is to reduce such ambiguities largely, while still preserving dynamic-typing spirit of the language (where it's needed). So, a compiler which employs my previous proposal https://mail.python.org/archives/list/python-ideas@python.org/thread/KGN4Q2EMOMGHLMUH4ITJB4ES7NR3FSB7/ will be able to optimize that to just CALL_FUNCTION in *most* cases. But not all cases, yeah. > > In a sense I don't. I intend to make very fine-grained, finely cut > > semantic *adjustments* > > If you come back when you've figured out exactly what those > adjustments will be and are able to explain them clearly, > we will have something to talk about. Again, the end of https://mail.python.org/archives/list/python-ideas@python.org/message/PF42DP2IYYRFUJMYCJ2NDRBXU57VNFEH/ drafts the scheme of the new proposed semantics (codenamed "the strict mode part 2"). I will also try to summarize it in a different (hopefully, clearer and more down-to-earth) way in a response to another participant. Eventually I'll also write down a full "spec", but that likely will take quite some time (and then will be a long read). So, if you happen to be really interested in that stuff, while waiting for the new spec, you may be interested to skim thru the previous part of the proposal, https://mail.python.org/archives/list/python-ideas@python.org/thread/KGN4Q2EMOMGHLMUH4ITJB4ES7NR3FSB7/ or formatted version at https://github.com/pycopy/PycoEPs/blob/master/StrictMode.md > -- > Greg -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/YPHACXFRVZY3LVXK5HFQWJGSB4TLHR4L/ Code of Conduct: http://python.org/psf/codeofconduct/
