Paul Moore wrote: > 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.
It's more work for the internals of python yes, because it becomes part of python stdlib that you can define a function with `.` in the signature and that has a specific meaning as syntax sugar for what's below. But that doesn't mean it's more work across the board, given that the below would be necessary for every single function that wanted to have this sort of syntax. In every single code base that wanted to use it. Granted no one would use it right now, because right now the effort of doing the below it prohibitive and misses out on the easy to ready signature definition. > > 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? It wouldn't need to be a new type of function, so yes of course you would be able to introspect these objects. The change does not require any real magic beyond the way you would do it now, except that it doubles the value of how you do it now by it being in a single neat function definition. > Extract the places in the name where the arguments can be interposed? If not, > why not? Assuming that it would just make each segment of the function name be a function with the next part as an attribute and have a return object yes you would be able to get where the arguments go in the signature. > How would a call like foo_(x)_bar(y) be parsed into the AST? Again, assuming the `.` syntax and a new "Return" class, it would be parse the same way `foo_(x)._bar(y)` would be. no magic needed > Would the original form be recoverable (black, for example, would want this). yes > 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. so, the underscores were a personal choice, because I separate words with underscores, but would not be necessary. Assuming (again) that it used a Return class for the intermediate returns with attributes for the next part, `foo(x)bar(y)` would not be an example, instead `foo(x).bar(y)` would be, which is using existing syntax and concepts. the main difference would be how this is initially defined, requiring only the presence of the `.` and interspersed args in the function signature. > > 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 no, I haven't misjudged it, I am not suggesting adding that at all. I think you misunderstand me. I am not saying that this is something broken about python, I am saying it would be cool, a nice to have, something that would make understanding some functions easier because the order of arguments is important but not obvious. When learning python, and even sometimes now, I have had to look at the implementation of a function in order to recall which order arguments should go. _______________________________________________ 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/WKACRFVB7Q2DIRAUCDUEBW4AH5SMJNTI/ Code of Conduct: http://python.org/psf/codeofconduct/
