How about global __main__ as a boolean? __name__ == '__main__' as a mark of entrypoint module is coherent and logical, but awkward to type and requires explicit explaination for newcomers even with prior background in other langauges.
On Mon, Jun 18, 2012 at 7:17 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
+1 Makes sense.... if __main__: sys.exit(main()) http://www.artima.com/weblogs/viewpost.jsp?thread=4829
Ethan Furman writes:
anatoly techtonik wrote:
How about global __main__ as a boolean?
-1 Saves typing, yes, but otherwise there's no point. It would need just as much explanation, for one thing.
Would it be writable? __main__ = False if __main__: print("Oh, I didn't want to run these tests anyway...")
anatoly techtonik writes:
It would be more convincing to have a solid counter argument for -1,
"Not every three-line function needs to be a builtin." "Explicit is better than implicit." "Simple is better than complex." "There should be one (and preferably only one) obvious way to do it."
or else I am inclined to count 'no point' arguments as -0.
Feel free; it doesn't matter to me, and I don't much matter to the decision, either. Not to mention that you don't do the counting. The people who will actually make a decision on this don't need it spelled out, though, and your ideas would get better reception from Those Whose Opinions Really Count if you would filter them through the Zen before posting.
On Mon, Jun 18, 2012 at 1:12 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
That's nonsense. If you wanted to support old Python versions, you'd write `if __name__ == '__main__'` (there's no reason __name__ would change its behavior). If the oldest version you wanted to support had this feature, you're write `if __main__`. This is the way every other new feature works. (It even has the advantage of failing loudly if you try to do it on an older version of Python.) That being said, I'm -0 on the feature. I don't think it's really much easier to explain or worth any effort. Mike
On Mon, Jun 18, 2012 at 01:25:11PM -0400, Mike Graham wrote:
That being said, I'm -0 on the feature. I don't think it's really much easier to explain or worth any effort.
I agree that having a boolean called "__main__" wouldn't add much value, but I believe that recognizing a function called "__main__" could potentially add a bit more value. After executing the body of a script, the interpreter would automatically call the "__main__" function if it exists, and exit with its return value. Thus: def __main__(): return 42 would be roughly equivalent to: if __name__ == '__main__': sys.exit(42) It might make sense to have "python -i" not call the "__main__" function, making it easier to interact with a script after the time that its methods and global variables are all defined but before the time that it enters __main__. I'm not sure if a "__main__" function would add enough value, but I think it would add more value than a "__main__" boolean. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
On Mon, Jun 18, 2012 at 9:59 PM, Jeremiah Dodds <jeremiah.dodds@gmail.com> wrote:
My first thoughts is that __main__() as a function is bad for Python, and here is why. In C, Java and other compiled languages so-called main() function is the primary execution entrypoint. With no main() there was no way to instruct compiler what should be run first, so logically it will just start with the first function at the top (and if you remember early compliers - you can only call functions that are already defined, that means written above yours). Code exection always started with main(). It was the first application byte to start with when program was loaded to memory by OS. In Python execution of a program code starts before the if __name__ == '__main__' is encountered (and it's awesome feature of a scripting language to start execution immediately). With automagical __main__() function it will also start before. That's why __main__() will never be the substitution for the classical C style entrypoint. In Python entrypoint is a module (entrypoint namespace). __name__ is equal to '__main__' not only in a script, but also in console. And __main__ as a flag in this namespace correctly reflects this semantic - "Is this a main namespace? True". A value of __name__ in console doesn't. So, __main__() function is not equivalent to C/Java entrypoint. However, a function like this may play an important role to mark the end of the "import phase" or "initialization phase". A high level concept that is extremely useful for web applications/servers/frameworks, who need to know when an application processes can be more effectively forked. Here is one more problem - when module is executed as a script, it loses its __name__, which becomes equal to '__main__'. I don't know if it ever caused any problems with imports or consistency in object space, or with static imports - it will be interesting to know any outcomes. What if module __name__ always meant module name? But that's another thread. As for __main__ - in this case instead of boolean it could be the name of the entrypoint module, and the check would be if __name__ == __main__ without quotes.
Le 19/06/2012 09:52, anatoly techtonik a écrit :
Here is one more problem - when module is executed as a script, it loses its __name__, which becomes equal to '__main__'.
PEP 395 "Qualified Names for Modules" tries to address this. http://www.python.org/dev/peps/pep-0395/ Regards, -- Simon Sapin
On Mon, Jun 18, 2012 at 11:05 AM, Andrew McNabb <amcnabb@mcnabbs.org> wrote:
The special value of __name__ and the proposed __main__() function are both a bit magic. However, when I write if __name__ == '__main__' it's at least clear that that if statement *will* be executed. It's just a question of when the condition is true and if I don't know I can find out fairly easily. (As I did the first time I saw it and probably other people on this list did too.) On the other hand, it's not at all obvious that a function named __main__ will be executed automagically. This will increase the python learning curve, because people will need to learn both the old method and the new method, especially since code that is compatible with multiple python versions will need to continue to use the old method. It saves one or two lines: if __name__ == '__main__': main() A __main__ boolean, that saves even less typing, and does not seem worth adding either. -1 for both --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
Massimo DiPierro wrote:
how about a decorator that have the same effect as calling the function is __name__=='__main__'?
I believe several have been written... something like (untested): def main(automagically_run): if __name__ == 'main': automagically_run() return automagically_run # assuming SystemExit wasn't raised ;) ~Ethan~
On Mon, Jun 18, 2012 at 12:39:05PM -0700, Bruce Leban wrote:
Given that C, Java, and numerous other languages automagically execute a function called "main", I would argue that a "__main__" function would actually be _less_ surprising than "if __name__ == '__main__'" for most new Python users.
If the only difference is saving a few lines, I agree that it probably isn't worth it. However, it also allows for a richer interactive mode as I mentioned previously, so the benefit may not be limited to the neglible number of lines saved. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
On Mon, 18 Jun 2012 14:09:33 -0600 Andrew McNabb <amcnabb@mcnabbs.org> wrote:
Yes, a __main__ function would be reasonable, especially now that we have __main__.py files in packages. Massimo's suggestion of a decorator, OTOH, sounds useless: how would it help in any way? Regards Antoine.
Andrew McNabb wrote:
What makes you think that "most" new users will be experienced in C or Java? I think it is more likely that the majority of new users will have no experience in programming at all, or that their primary experience will be in PHP or Javascript. But we're all just guessing really. I don't think any of us know what languages most current Python users came from, let alone what future ones will come from. But as a matter of principle, I would prefer to assume that new users come in with as few preconceived ideas as possible, rather than assuming that they expect Python to be just like <insert language of choice here>. -- Steven
I'm afraid you're the one who's missed the point... the interpreter would only call __main__() if __name__ == "__main__" Some people will cry "magic", but to me this is about what makes sense when you explain it to someone, and I think __main__() makes more sense (especially to someone with experience in other languages) than "if __name__ == "__main__"" Matt
On 6/18/2012 6:39 PM, Matt Chaput wrote:
I understand the proposal now, and yes, it is "magic". Explicit is better than implicit. I like this explanation: "When you run a Python program, all the statements are run, from top to bottom." better than, "When you run a Python program, all the statements are run, from top to bottom, and then if there is a __main__ function (which there need not be), then it is invoked." Python is full of constructs that are simpler than other languages, which when used in conventional ways, act similar to other languages. No need to complicate things to make it easier for C programmers to understand. There's a lot they need to get used to in Python, and "if __name__ == '__main__':" is not difficult. --Ned.
anatoly techtonik schrieb am Mon, 18. Jun 2012, um 18:26:59 +0300:
How about global __main__ as a boolean?
Currently, __main__ is the name of a module. You can do import __main__ to import this module. After this import, __main__ evaluates to True as a Boolean expression. I don't think it's a good idea to overload the meaning of the __main__. Cheers, Sven
On Mon, Jun 18, 2012 at 7:17 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
+1 Makes sense.... if __main__: sys.exit(main()) http://www.artima.com/weblogs/viewpost.jsp?thread=4829
Ethan Furman writes:
anatoly techtonik wrote:
How about global __main__ as a boolean?
-1 Saves typing, yes, but otherwise there's no point. It would need just as much explanation, for one thing.
Would it be writable? __main__ = False if __main__: print("Oh, I didn't want to run these tests anyway...")
anatoly techtonik writes:
It would be more convincing to have a solid counter argument for -1,
"Not every three-line function needs to be a builtin." "Explicit is better than implicit." "Simple is better than complex." "There should be one (and preferably only one) obvious way to do it."
or else I am inclined to count 'no point' arguments as -0.
Feel free; it doesn't matter to me, and I don't much matter to the decision, either. Not to mention that you don't do the counting. The people who will actually make a decision on this don't need it spelled out, though, and your ideas would get better reception from Those Whose Opinions Really Count if you would filter them through the Zen before posting.
On Mon, Jun 18, 2012 at 1:12 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
That's nonsense. If you wanted to support old Python versions, you'd write `if __name__ == '__main__'` (there's no reason __name__ would change its behavior). If the oldest version you wanted to support had this feature, you're write `if __main__`. This is the way every other new feature works. (It even has the advantage of failing loudly if you try to do it on an older version of Python.) That being said, I'm -0 on the feature. I don't think it's really much easier to explain or worth any effort. Mike
On Mon, Jun 18, 2012 at 01:25:11PM -0400, Mike Graham wrote:
That being said, I'm -0 on the feature. I don't think it's really much easier to explain or worth any effort.
I agree that having a boolean called "__main__" wouldn't add much value, but I believe that recognizing a function called "__main__" could potentially add a bit more value. After executing the body of a script, the interpreter would automatically call the "__main__" function if it exists, and exit with its return value. Thus: def __main__(): return 42 would be roughly equivalent to: if __name__ == '__main__': sys.exit(42) It might make sense to have "python -i" not call the "__main__" function, making it easier to interact with a script after the time that its methods and global variables are all defined but before the time that it enters __main__. I'm not sure if a "__main__" function would add enough value, but I think it would add more value than a "__main__" boolean. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
On Mon, Jun 18, 2012 at 9:59 PM, Jeremiah Dodds <jeremiah.dodds@gmail.com> wrote:
My first thoughts is that __main__() as a function is bad for Python, and here is why. In C, Java and other compiled languages so-called main() function is the primary execution entrypoint. With no main() there was no way to instruct compiler what should be run first, so logically it will just start with the first function at the top (and if you remember early compliers - you can only call functions that are already defined, that means written above yours). Code exection always started with main(). It was the first application byte to start with when program was loaded to memory by OS. In Python execution of a program code starts before the if __name__ == '__main__' is encountered (and it's awesome feature of a scripting language to start execution immediately). With automagical __main__() function it will also start before. That's why __main__() will never be the substitution for the classical C style entrypoint. In Python entrypoint is a module (entrypoint namespace). __name__ is equal to '__main__' not only in a script, but also in console. And __main__ as a flag in this namespace correctly reflects this semantic - "Is this a main namespace? True". A value of __name__ in console doesn't. So, __main__() function is not equivalent to C/Java entrypoint. However, a function like this may play an important role to mark the end of the "import phase" or "initialization phase". A high level concept that is extremely useful for web applications/servers/frameworks, who need to know when an application processes can be more effectively forked. Here is one more problem - when module is executed as a script, it loses its __name__, which becomes equal to '__main__'. I don't know if it ever caused any problems with imports or consistency in object space, or with static imports - it will be interesting to know any outcomes. What if module __name__ always meant module name? But that's another thread. As for __main__ - in this case instead of boolean it could be the name of the entrypoint module, and the check would be if __name__ == __main__ without quotes.
Le 19/06/2012 09:52, anatoly techtonik a écrit :
Here is one more problem - when module is executed as a script, it loses its __name__, which becomes equal to '__main__'.
PEP 395 "Qualified Names for Modules" tries to address this. http://www.python.org/dev/peps/pep-0395/ Regards, -- Simon Sapin
On Mon, Jun 18, 2012 at 11:05 AM, Andrew McNabb <amcnabb@mcnabbs.org> wrote:
The special value of __name__ and the proposed __main__() function are both a bit magic. However, when I write if __name__ == '__main__' it's at least clear that that if statement *will* be executed. It's just a question of when the condition is true and if I don't know I can find out fairly easily. (As I did the first time I saw it and probably other people on this list did too.) On the other hand, it's not at all obvious that a function named __main__ will be executed automagically. This will increase the python learning curve, because people will need to learn both the old method and the new method, especially since code that is compatible with multiple python versions will need to continue to use the old method. It saves one or two lines: if __name__ == '__main__': main() A __main__ boolean, that saves even less typing, and does not seem worth adding either. -1 for both --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
Massimo DiPierro wrote:
how about a decorator that have the same effect as calling the function is __name__=='__main__'?
I believe several have been written... something like (untested): def main(automagically_run): if __name__ == 'main': automagically_run() return automagically_run # assuming SystemExit wasn't raised ;) ~Ethan~
On Mon, Jun 18, 2012 at 12:39:05PM -0700, Bruce Leban wrote:
Given that C, Java, and numerous other languages automagically execute a function called "main", I would argue that a "__main__" function would actually be _less_ surprising than "if __name__ == '__main__'" for most new Python users.
If the only difference is saving a few lines, I agree that it probably isn't worth it. However, it also allows for a richer interactive mode as I mentioned previously, so the benefit may not be limited to the neglible number of lines saved. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
On Mon, 18 Jun 2012 14:09:33 -0600 Andrew McNabb <amcnabb@mcnabbs.org> wrote:
Yes, a __main__ function would be reasonable, especially now that we have __main__.py files in packages. Massimo's suggestion of a decorator, OTOH, sounds useless: how would it help in any way? Regards Antoine.
Andrew McNabb wrote:
What makes you think that "most" new users will be experienced in C or Java? I think it is more likely that the majority of new users will have no experience in programming at all, or that their primary experience will be in PHP or Javascript. But we're all just guessing really. I don't think any of us know what languages most current Python users came from, let alone what future ones will come from. But as a matter of principle, I would prefer to assume that new users come in with as few preconceived ideas as possible, rather than assuming that they expect Python to be just like <insert language of choice here>. -- Steven
I'm afraid you're the one who's missed the point... the interpreter would only call __main__() if __name__ == "__main__" Some people will cry "magic", but to me this is about what makes sense when you explain it to someone, and I think __main__() makes more sense (especially to someone with experience in other languages) than "if __name__ == "__main__"" Matt
On 6/18/2012 6:39 PM, Matt Chaput wrote:
I understand the proposal now, and yes, it is "magic". Explicit is better than implicit. I like this explanation: "When you run a Python program, all the statements are run, from top to bottom." better than, "When you run a Python program, all the statements are run, from top to bottom, and then if there is a __main__ function (which there need not be), then it is invoked." Python is full of constructs that are simpler than other languages, which when used in conventional ways, act similar to other languages. No need to complicate things to make it easier for C programmers to understand. There's a lot they need to get used to in Python, and "if __name__ == '__main__':" is not difficult. --Ned.
anatoly techtonik schrieb am Mon, 18. Jun 2012, um 18:26:59 +0300:
How about global __main__ as a boolean?
Currently, __main__ is the name of a module. You can do import __main__ to import this module. After this import, __main__ evaluates to True as a Boolean expression. I don't think it's a good idea to overload the meaning of the __main__. Cheers, Sven
participants (18)
-
Alexandre Zani -
anatoly techtonik -
Andrew McNabb -
Antoine Pitrou -
Bruce Leban -
Ethan Furman -
Jakob Bowyer -
Jeremiah Dodds -
Massimo DiPierro -
Matt Chaput -
Mike Graham -
Ned Batchelder -
Serhiy Storchaka -
Simon Sapin -
Stephen J. Turnbull -
Steven D'Aprano -
Sven Marnach -
Yuval Greenfield