Define functions without parentheses (if no parameters given)
The syntax to define a class looks like this: class MyClass: pass Nice and neat. *** And the syntax to define a function looks like this: def my_function(): pass Hmmm... *** What if we could define functions (that don't have any parameters) like this: def my_function: pass *** Is that a possible scenario at this point, or even desirable?
Boštjan Mejak writes:
I'm sure it's possible, but the argument lists are very different in nature. (1) The superclasses optionally passed to class are actual classes and have no necessary relation to the class body, while the identifiers passed to def are formal arguments which declare their use to the function body. (2) object is always an implied superclass, so "class Foo():" doesn't mean "no superclass", whereas "def foo():" *does* mean "no arguments." So the analogy doesn't really stand up. It's not necessarily undesirable, but what benefit is there other than saving a couple of keystrokes? I don't see how def myfunction: pass is more readable than def myfunction(): pass Python is strongly conservative about these things; this is unlikely to get any uptake unless you can show a benefit bigger than saving two keystrokes on a relatively uncommon construct. In the case of class, on the other hand, requiring "(object)" is a fair amount of clutter that is never necessary because object is always present as the root of the class hierarchy. It might be more consistent to require the parentheses, but that's not obvious to me. Steve
Thank you, Steve, for your answer. You're absolutely right. But I needed an answer to clarify that my idea, well, sucks. I was just relating to class definitions -- being able to do 'class MyClass: pass' -- and had an idea about having this same non-parenthesized version in case of no given parameters in a function definition.
On 10Jun2021 23:07, Boštjan Mejak <bostjan.xperia@gmail.com> wrote:
It doesn't suck. Consider, for example, a lambda with no parameters: random16 = lambda: random.randint(1, 16) Stephen is saying it isn't a gleaming nugget of gold that wants, nay, _demands_ to be implelemented. It does really only save a couple of characters and a little visual noise. Another thing to keep in mind with any syntax suggestion (not that it applies well here, because really, what else can your suggestion mean?) it that every addition syntax is a detour into the unused space of possible token paths. This is because the exsiting grammar defines a space of _used_ token paths with existing meanings. Allowing a new path of previously illegal tokens (==> unused and therefore available) should bring a specific benefit, as it _precludes_ that path/syntax from being used for anything else. Python tends to be pretty conservative here: if what you want to write this way can _already_ be written another way which is not really very worse, the benefit the new way brings is small. In a sense this is a similar criterion to the oft cited view that "not everything needs its own function", usually applied to advocating for small one/few line functions to be added to the standard library. So your idea does not suck. But it may not motivate anyone to implement it, or even to agreed that it should be implemented. Cheers, Cameron Simpson <cs@cskk.id.au>
On 11Jun2021 10:01, Cameron Simpson <cs@cskk.id.au> wrote:
So your idea does not suck. But it may not motivate anyone to implement it, or even to agreed that it should be implemented.
It also struck me: functions with _no_ parameters are pretty rare. I had a glance through my own code and aside from some closures (functions within a running function, getting their variables from the enclosing scope) I've got a few which either access state from some global or which generate something standalone, eg a primes() function which just generates the primes starting from 2, a function I maybe even don't use. They are very few. So these seem pretty rare. Just how often do you write such a function yourself? Got a real world example? I'm making an argument that this is already a pretty niche situation here. Cheers, Cameron Simpson <cs@cskk.id.au>
non sequitur Route functions as seen in flask or fastapi. These functions are often decorated by a route, and may not apply here but are often found with routes that return a page that doesn't take parameters such as a home page or a contact page. On Thu, Jun 10, 2021, 10:30 PM Cameron Simpson <cs@cskk.id.au> wrote:
On Fri, Jun 11, 2021 at 7:47 AM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
I'm sure the idea is dead now, but it reminds me of an amusing anecdote I heard in college. You may not have heard of a language named Algol-68, but it was a big thing when I learned programming in Amsterdam in the late '70s. Like its predecessor, Algol-60, it had a feature where parameter-less functions could both be *defined* and *called* without parentheses. Now, in Algol-60, this was easy, because there were no function pointers, so whenever the compiler saw the name of a parameter-less function, it would generate the code to call it. (Example: "x := random*2".) But Algol-68 *did* have function pointers, so the language design committee had to introduce a complicated wrinkle into the type system so that you could write things like "f := random" (interpreting it as a function pointer) but also "x := 2*random" (calling it). The distinguishing property was the type of the receiving end (i.e., f had to be declared as a parameterless function pointer, and x had to be a number). So one of the classes I took near the end of my studies was taught by the lead author of Algol-68 (Adriaan van Wijngaarden). He was well respected and near retirement age, so he could do what he wanted in class, and sometimes he just told anecdotes from the past (I'd love such a job :-). One day the issue with parameter-less functions came up, and by then a new language named C had gained some notoriety. C, of course, has function pointers and parameter-less functions, but both the declaration and the call must use an empty pair of parentheses (i.e, "x = 2*random()", like Python). Van Wijngaarden told us, somewhat ruefully, that, had the design committee known that programmers would be happy to write that empty pair of parentheses, they would have been able to simplify a significant corner of Algol-68's type system. This was one of the seminal ideas that went into Python's design. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Fri, Jun 11, 2021 at 10:01:06AM +1000, Cameron Simpson wrote:
I'm not arguing for or against it, but parenthesis-free definitions "could" mean something rather different, such as (let's say) a function that uses dynamic scoping instead of lexical, and always gets its arguments from the calling scope. def func: return min(a, 10) # first caller a = 5 print(func()) # --> 5 # second caller def my_function(): a = 20 print(func()) my_function() # --> 10 If I wanted dynamic scopes, I wouldn't design the API that way. But we could. Another possibility would be computed values (sort of like properties): def now: return strftime('%H:%M:%S') print(now) # --> 21:23:20 time.sleep(15) print(now) # --> 21:23:35 The point here is to agree with Cameron that every time we choose to use syntax for one thing, that precludes us from using that same syntax for a different thing. -- Steve
Boštjan Mejak writes:
I'm sure it's possible, but the argument lists are very different in nature. (1) The superclasses optionally passed to class are actual classes and have no necessary relation to the class body, while the identifiers passed to def are formal arguments which declare their use to the function body. (2) object is always an implied superclass, so "class Foo():" doesn't mean "no superclass", whereas "def foo():" *does* mean "no arguments." So the analogy doesn't really stand up. It's not necessarily undesirable, but what benefit is there other than saving a couple of keystrokes? I don't see how def myfunction: pass is more readable than def myfunction(): pass Python is strongly conservative about these things; this is unlikely to get any uptake unless you can show a benefit bigger than saving two keystrokes on a relatively uncommon construct. In the case of class, on the other hand, requiring "(object)" is a fair amount of clutter that is never necessary because object is always present as the root of the class hierarchy. It might be more consistent to require the parentheses, but that's not obvious to me. Steve
Thank you, Steve, for your answer. You're absolutely right. But I needed an answer to clarify that my idea, well, sucks. I was just relating to class definitions -- being able to do 'class MyClass: pass' -- and had an idea about having this same non-parenthesized version in case of no given parameters in a function definition.
On 10Jun2021 23:07, Boštjan Mejak <bostjan.xperia@gmail.com> wrote:
It doesn't suck. Consider, for example, a lambda with no parameters: random16 = lambda: random.randint(1, 16) Stephen is saying it isn't a gleaming nugget of gold that wants, nay, _demands_ to be implelemented. It does really only save a couple of characters and a little visual noise. Another thing to keep in mind with any syntax suggestion (not that it applies well here, because really, what else can your suggestion mean?) it that every addition syntax is a detour into the unused space of possible token paths. This is because the exsiting grammar defines a space of _used_ token paths with existing meanings. Allowing a new path of previously illegal tokens (==> unused and therefore available) should bring a specific benefit, as it _precludes_ that path/syntax from being used for anything else. Python tends to be pretty conservative here: if what you want to write this way can _already_ be written another way which is not really very worse, the benefit the new way brings is small. In a sense this is a similar criterion to the oft cited view that "not everything needs its own function", usually applied to advocating for small one/few line functions to be added to the standard library. So your idea does not suck. But it may not motivate anyone to implement it, or even to agreed that it should be implemented. Cheers, Cameron Simpson <cs@cskk.id.au>
On 11Jun2021 10:01, Cameron Simpson <cs@cskk.id.au> wrote:
So your idea does not suck. But it may not motivate anyone to implement it, or even to agreed that it should be implemented.
It also struck me: functions with _no_ parameters are pretty rare. I had a glance through my own code and aside from some closures (functions within a running function, getting their variables from the enclosing scope) I've got a few which either access state from some global or which generate something standalone, eg a primes() function which just generates the primes starting from 2, a function I maybe even don't use. They are very few. So these seem pretty rare. Just how often do you write such a function yourself? Got a real world example? I'm making an argument that this is already a pretty niche situation here. Cheers, Cameron Simpson <cs@cskk.id.au>
non sequitur Route functions as seen in flask or fastapi. These functions are often decorated by a route, and may not apply here but are often found with routes that return a page that doesn't take parameters such as a home page or a contact page. On Thu, Jun 10, 2021, 10:30 PM Cameron Simpson <cs@cskk.id.au> wrote:
On Fri, Jun 11, 2021 at 7:47 AM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
I'm sure the idea is dead now, but it reminds me of an amusing anecdote I heard in college. You may not have heard of a language named Algol-68, but it was a big thing when I learned programming in Amsterdam in the late '70s. Like its predecessor, Algol-60, it had a feature where parameter-less functions could both be *defined* and *called* without parentheses. Now, in Algol-60, this was easy, because there were no function pointers, so whenever the compiler saw the name of a parameter-less function, it would generate the code to call it. (Example: "x := random*2".) But Algol-68 *did* have function pointers, so the language design committee had to introduce a complicated wrinkle into the type system so that you could write things like "f := random" (interpreting it as a function pointer) but also "x := 2*random" (calling it). The distinguishing property was the type of the receiving end (i.e., f had to be declared as a parameterless function pointer, and x had to be a number). So one of the classes I took near the end of my studies was taught by the lead author of Algol-68 (Adriaan van Wijngaarden). He was well respected and near retirement age, so he could do what he wanted in class, and sometimes he just told anecdotes from the past (I'd love such a job :-). One day the issue with parameter-less functions came up, and by then a new language named C had gained some notoriety. C, of course, has function pointers and parameter-less functions, but both the declaration and the call must use an empty pair of parentheses (i.e, "x = 2*random()", like Python). Van Wijngaarden told us, somewhat ruefully, that, had the design committee known that programmers would be happy to write that empty pair of parentheses, they would have been able to simplify a significant corner of Algol-68's type system. This was one of the seminal ideas that went into Python's design. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Fri, Jun 11, 2021 at 10:01:06AM +1000, Cameron Simpson wrote:
I'm not arguing for or against it, but parenthesis-free definitions "could" mean something rather different, such as (let's say) a function that uses dynamic scoping instead of lexical, and always gets its arguments from the calling scope. def func: return min(a, 10) # first caller a = 5 print(func()) # --> 5 # second caller def my_function(): a = 20 print(func()) my_function() # --> 10 If I wanted dynamic scopes, I wouldn't design the API that way. But we could. Another possibility would be computed values (sort of like properties): def now: return strftime('%H:%M:%S') print(now) # --> 21:23:20 time.sleep(15) print(now) # --> 21:23:35 The point here is to agree with Cameron that every time we choose to use syntax for one thing, that precludes us from using that same syntax for a different thing. -- Steve
participants (7)
-
Boštjan Mejak -
Cameron Simpson -
Guido van Rossum -
Jelle Zijlstra -
Johnathan Irvin -
Stephen J. Turnbull -
Steven D'Aprano