On Mon, 18 Oct 2021 at 12:49, Mathew Elman <mathew.el...@ocado.com> wrote: > > The point is that at the moment to set this sort of api up requires a lot of > work, defeating 50% of the value i.e. to define a new function with the > attribute access behaviour requires defining each individual function to > return a middle step object that has the attribute of the next function, so > you can't define a function in plain english.
Adding a new feature to a language is *even more* work, though. The reason (one of the reasons) we'd add a feature to the language is because it would get used so often that the repeated saving outweighs the initial (and ongoing) cost of the language feature. > e.g. > > def insert_into(x, y): > ... > > def insert(x): > class Return: > def into(self, y): > return insert_into(x, y) > return Return() > > insert.into = insert_into > > is a very long way to say: > > def insert(x)._into(y): > ... > > and that is without the actual logic and for only 2 positional args. > > > > But why would you? It's ugly if spelled like that, and your whole argument > > is that the "interspersed arguments" form is better. If you just want to > > pass the function to something that expects "normal" argument conventions, > > lambda x,y: insert(x).into(y) does what you want. > > The point is so that in code that expects dynamically called functions or to > be able to reference the function by name it needs to have a single name that > follows backward compatible naming conventions. I would be happy with it > being on the onus of the developer in question to add a wrapping function, > less happy than if it was added by default but it would still be a saving > (and could maybe be in a decorator or something). So the automatic definition of the extra name is purely because there's no other way to pass these types of function around as first-class objects? What about other aspects of first class functions - would you be able to introspect these new types of function? Extract the places in the name where the arguments can be interposed? If not, why not? How would a call like foo_(x)_bar(y) be parsed into the AST? Would the original form be recoverable (black, for example, would want this). Also, are the underscores part of the syntax? Is foo(x)bar(y) a single function call using your new syntax? If not, why not? You would be making underscores into special syntax otherwise. > > I've never heard anyone else suggest anything like this, so you might want > > to consider that the annoyance you feel is not a common reaction... > > I know lots of people that have had this reaction but just shrugged it off as > "the way things are", which would seem like a good way to stagnate a > language, so I thought I would ask. There seem to be a lot of open design questions. Do you have any examples of prior art? Languages that implement this type of syntax, and otherwise have the sort of capabilities that Python does (as David Mertz noted, Cobol had this sort of "English like" syntax, but it didn't have first class function objects. > I see this argument used for python in this list (and in the wild) a lot i.e. > that it should be readable in English That's an over-simplification, and TBH I suspect that most people using the argument know that. Python should be readable in the sense that it should have a generally natural looking syntax, use keywords that read naturally in English, and generally be accessible to people familiar with English. It does *not* mean that English word order must be adhered to, or that technical or abbreviated terms cannot be used (we use "def" rather than "define", and "class" means something very different from the non-computing meaning). Taking "readable in English" to its "logical" conclusion results in "ADD 7 TO X" rather than "x = x + 7" and if you think that a proposal to add that syntax to Python would be well-received, you've badly misjudged both the design principles of Python and the attitude of this mailing list... Paul _______________________________________________ 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/Y435OHRF5E4LGLMZX4GX7HVOB65YAROY/ Code of Conduct: http://python.org/psf/codeofconduct/
