Re: [Python-Dev] PEP 328 and PEP 338, redux
Guido van Rossum wrote: On 6/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: The workaround to replace __name__ with __module_name__ in order to enable relative imports turned out to be pretty ugly, so I also worked up a patch to import.c to get it to treat __module_name__ as an override for __name__ when __name__ == '__main__'. Ah, clever. +1. In that case, I'll check it straight in. It was actually surprisingly easy to do, given how finicky import.c can get (this particular change was able to be handled entirely inside get_parent()). So given a test_foo.py that started like this: import unittest import ..foo Um, that's not legal syntax last I looked. Leading dots can only be used in from ... import. Did you change that too? I really hope you didn't! It's OK - I just spelt it wrong in the example. It should have said from .. import foo. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Giovanni Bajo wrote: Guido van Rossum wrote: This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. Could this be reconsidered for Py3k? You have a point. AFAICT, there's nothing preventing it from being added in 2.6. It won't break existing code with the if name == main paradigm. Writing modules that use the approach but want to work with both 2.5 and 2.6 becomes a little more annoying - such modules have to finish with the coda: if __name__ == '__main__': from sys import version_info, argv if version_info (2, 6): sys.exit(__main__(argv)) The interpreter would also have to be careful to ensure that a __main__ variable in the globals isn't the result of a module doing import __main__. The above two reasons are what got PEP 299 killed the first time (the thread is even linked from the PEP ;). Another downside I've discovered recently is that calling sys.exit() prevents the use of a post-mortem debugging session triggered by -i or PYTHONINSPECT. sys.exit() crashes out of the entire process, so the post-mortem interactive session never even gets started. The only real upside I can see to PEP 299 is that main is a function is more familiar to people coming from languages like C where you can't have run-time code at the top level of a module. Python's a scripting language though, and having run-time logic at the top level of a script is perfectly normal! Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Nick Coghlan wrote: Writing modules that use the approach but want to work with both 2.5 and 2.6 becomes a little more annoying - such modules have to finish with the coda: if __name__ == '__main__': from sys import version_info, argv if version_info (2, 6): sys.exit(__main__(argv)) Actually, this should be enough: if __name__ == '__main__': sys.exit(__main__(argv)) and it will still work for the python -mpackage.module case which we're discussing about. The if suite can be dropped when you won't need pre-2.6 compatibility anymore. The interpreter would also have to be careful to ensure that a __main__ variable in the globals isn't the result of a module doing import __main__. Real-world usage case for import __main__? Otherwise, I say screw it :) Another downside I've discovered recently is that calling sys.exit() prevents the use of a post-mortem debugging session triggered by -i or PYTHONINSPECT. sys.exit() crashes out of the entire process, so the post-mortem interactive session never even gets started. In fact, this is an *upside* of implementing the __main__ PEP, because the call to sys.exit() is not needed in that case. All of my Python programs right now need a sys.exit() *because* the __main__ PEP was not implemented. The only real upside I can see to PEP 299 is that main is a function is more familiar to people coming from languages like C where you can't have run-time code at the top level of a module. Python's a scripting language though, and having run-time logic at the top level of a script is perfectly normal! My personal argument is that if __name__ == '__main__' is totally counter-intuitve and unpythonic. It also proves my memory: after many years, I still have to think a couple of seconds before rememebering whether I should use __file__, __name__ or __main__ and where to put the damn quotes. The fact that you're comparing a variable name and a string literal which seems very similar (both with the double underscore syntax) is totally confusing at best. Also, try teaching it to a beginner and he will go huh wtf. To fully understand it, you must understand how import exactly works (that is, the fact that importing a module equals evaluating all of its statement one by one). A function called __main__ which is magically invoked by the python itself is much much easier to grasp. A different, clearer spelling for the if condition (like: if not __imported__) would help as well. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On Thursday 29 June 2006 20:56, Nick Coghlan wrote: Guido van Rossum wrote: On 6/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: The workaround to replace __name__ with __module_name__ in order to enable relative imports turned out to be pretty ugly, so I also worked up a patch to import.c to get it to treat __module_name__ as an override for __name__ when __name__ == '__main__'. Ah, clever. +1. In that case, I'll check it straight in. It was actually surprisingly easy to do, given how finicky import.c can get (this particular change was able to be handled entirely inside get_parent()). Please, please DON'T. At this point in the release cycle, making a change like this without review (particularly to something as diabolically hairy as import.c) is going to make me _unbelievably_ cranky. I'll try to make time to review the patch you posted tomorrow. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On 6/29/06, Giovanni Bajo [EMAIL PROTECTED] wrote: Real-world usage case for import __main__? Otherwise, I say screw it :) [...] My personal argument is that if __name__ == '__main__' is totally counter-intuitve and unpythonic. It also proves my memory: after many years, I still have to think a couple of seconds before rememebering whether I should use __file__, __name__ or __main__ and where to put the damn quotes. The fact that you're comparing a variable name and a string literal which seems very similar (both with the double underscore syntax) is totally confusing at best. Also, try teaching it to a beginner and he will go huh wtf. To fully understand it, you must understand how import exactly works (that is, the fact that importing a module equals evaluating all of its statement one by one). A function called __main__ which is magically invoked by the python itself is much much easier to grasp. A different, clearer spelling for the if condition (like: if not __imported__) would help as well. You need to watch your attitude, and try to present better arguments than I don't like it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Guido van Rossum wrote: Real-world usage case for import __main__? Otherwise, I say screw it :) [...] My personal argument is that if __name__ == '__main__' is totally counter-intuitve and unpythonic. It also proves my memory: after many years, I still have to think a couple of seconds before rememebering whether I should use __file__, __name__ or __main__ and where to put the damn quotes. The fact that you're comparing a variable name and a string literal which seems very similar (both with the double underscore syntax) is totally confusing at best. Also, try teaching it to a beginner and he will go huh wtf. To fully understand it, you must understand how import exactly works (that is, the fact that importing a module equals evaluating all of its statement one by one). A function called __main__ which is magically invoked by the python itself is much much easier to grasp. A different, clearer spelling for the if condition (like: if not __imported__) would help as well. You need to watch your attitude, and try to present better arguments than I don't like it. Sorry for the attitude. I though I brought arguments against if __name__: - Harder to learn for beginners (requires deeper understanding of import workings) - Harder to remember (a string literal compared to a name with the same naming convention) - Often requires explicit sys.exit() which breaks python -i - Broken by -mpkg.mod, and we ended up with another __magic_name__ just because of this. - (new) Defining a main() function is already the preferred style for reusability, so __main__ would encourage the preferred style. If you believe that these arguments collapse to I don't like it, then no, I don't have any arguments. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 328 and PEP 338, redux
Real-world usage case for import __main__? Typically for inter-module communication. A standard name (such as lobby, or __settings__) would work as well, but __main__ is what we have, for backwards compatibility. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Guido van Rossum wrote: However, I'm fine with setting *another* variable to the full package name so someone who *really* wants to do relative imports here knows the package name. OK, I'll do that. Any objections to __module_name__ as the name of the variable? (to keep things simple, run_module() will always define the variable, even if __name__ and __module_name__ say the same thing). I'll then put a note in PEP 338 about the necessary hackery to make relative imports work correctly from a main module - I don't see any reason to include something like that in the normal docs, since the recommended approach is for main modules to use absolute imports. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Nick Coghlan wrote: Guido van Rossum wrote: However, I'm fine with setting *another* variable to the full package name so someone who *really* wants to do relative imports here knows the package name. OK, I'll do that. Any objections to __module_name__ as the name of the variable? (to keep things simple, run_module() will always define the variable, even if __name__ and __module_name__ say the same thing). I'll then put a note in PEP 338 about the necessary hackery to make relative imports work correctly from a main module - I don't see any reason to include something like that in the normal docs, since the recommended approach is for main modules to use absolute imports. These two bits have been done. The workaround to replace __name__ with __module_name__ in order to enable relative imports turned out to be pretty ugly, so I also worked up a patch to import.c to get it to treat __module_name__ as an override for __name__ when __name__ == '__main__'. With the patch in place, relative imports from a main module executed using '-m' would work out of the box. So given a test_foo.py that started like this: import unittest import ..foo # Define the tests # Run the tests if __name__ = '__main__' A file layout like this: /home /ncoghlan /devel /package /__init__.py /foo.py /test /__init__.py /test_foo.py And a current working directory of /home/ncoghlan/devel, then the tests could be run simply by doing: python -m package.test.test_foo With beta 1 or current SVN, that would blow up with a ValueError. We can't do anything to help directly executed files, though - the interpreter simply doesn't have access to the info it needs in order to determine the location of such files in the module namespace. I'll post the patch to SF tomorrow (assuming the site decides to come back by then). In addition to the import.c changes, the patch includes some additional tests for runpy that exercise this and make sure it works, since runpy is the intended client. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On 6/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: The workaround to replace __name__ with __module_name__ in order to enable relative imports turned out to be pretty ugly, so I also worked up a patch to import.c to get it to treat __module_name__ as an override for __name__ when __name__ == '__main__'. Ah, clever. +1. So given a test_foo.py that started like this: import unittest import ..foo Um, that's not legal syntax last I looked. Leading dots can only be used in from ... import. Did you change that too? I really hope you didn't! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Guido van Rossum wrote: This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. Could this be reconsidered for Py3k? You have a point. AFAICT, there's nothing preventing it from being added in 2.6. It won't break existing code with the if name == main paradigm. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Guido van Rossum wrote: On 6/27/06, Greg Ewing [EMAIL PROTECTED] wrote: Giovanni Bajo wrote: This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. Could this be reconsidered for Py3k? You have a point. Added to PEP 3100. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 328 and PEP 338, redux
Mitch Chapman [1] tripped over the fact that relative imports don't like main
modules because __name__ doesn't contain any package hierarchy information.
It occurred to me that a slight modification to PEP 338 might solve the
problem fairly cleanly: instead of simply setting __name__ to '__main__' for a
module in a package, the -m switch could prepend the package name so that
relative imports can work correctly.
Inside the module, the test for am I the main module would need to be
__name__.endswith('__main__') instead of __name__ == '__main__', but other
than that, there should be very little impact.
By sticking the main module into sys.modules under two different names (once
with the package prefix and once without), runpy could even take care of
ensuring that the following invariant held:
import __main__
by_name = __import__(__main__.__name__)
assert by_name is __main__
The behaviour of top level modules would be unaffected, since they won't have
a package prefix.
Cheers,
Nick.
[1] http://www.python.org/sf/1510172
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On 6/27/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Mitch Chapman [1] tripped over the fact that relative imports don't like main
modules because __name__ doesn't contain any package hierarchy information.
It occurred to me that a slight modification to PEP 338 might solve the
problem fairly cleanly: instead of simply setting __name__ to '__main__' for a
module in a package, the -m switch could prepend the package name so that
relative imports can work correctly.
Inside the module, the test for am I the main module would need to be
__name__.endswith('__main__') instead of __name__ == '__main__', but other
than that, there should be very little impact.
By sticking the main module into sys.modules under two different names (once
with the package prefix and once without), runpy could even take care of
ensuring that the following invariant held:
import __main__
by_name = __import__(__main__.__name__)
assert by_name is __main__
The behaviour of top level modules would be unaffected, since they won't have
a package prefix.
Cheers,
Nick.
[1] http://www.python.org/sf/1510172
Bad idea IMO. The __name__ == __main__ rule is so ingrained, you
don't want to mess with it.
Such a main module ought to use an *absolute* import to reach into the
rest of the package.
However, I'm fine with setting *another* variable to the full package
name so someone who *really* wants to do relative imports here knows
the package name.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On 27 Jun 2006, at 13:03, Nick Coghlan wrote:
...
It occurred to me that a slight modification to PEP 338 might solve
the
problem fairly cleanly: instead of simply setting __name__ to
'__main__' for a
module in a package, the -m switch could prepend the package name
so that
relative imports can work correctly.
Inside the module, the test for am I the main module would need
to be
__name__.endswith('__main__') instead of __name__ ==
'__main__', but other
than that, there should be very little impact.
Hum... other than effecting more or less every runnable python module
around it should be very little impact. That sounds like quite a bit
of impact to me!
Nicko
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote: Bad idea IMO. The __name__ == __main__ rule is so ingrained, you don't want to mess with it. Actually, maybe we *do* want to, for this usage. Note that until Python 2.5, it was not possible to do python -m nested.module, so this change merely prevents *existing* modules from being run this way -- when they could not have been before! So, such modules would require a minor change to run under -m. Is this actually a problem, or is it a new feature? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Phillip J. Eby wrote: Actually, maybe we *do* want to, for this usage. Note that until Python 2.5, it was not possible to do python -m nested.module, so this change merely prevents *existing* modules from being run this way -- when they could not have been before! So, such modules would require a minor change to run under -m. Is this actually a problem, or is it a new feature? This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On 6/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote: Bad idea IMO. The __name__ == __main__ rule is so ingrained, you don't want to mess with it. Actually, maybe we *do* want to, for this usage. Note that until Python 2.5, it was not possible to do python -m nested.module, so this change merely prevents *existing* modules from being run this way -- when they could not have been before! So, such modules would require a minor change to run under -m. Is this actually a problem, or is it a new feature? It's a feature with a problem, that's what it is. :-) My main concern is that people will feel the requirement to change all existing main programs to use the endswith() idiom whether they need it or not; there's a powerful meme that says you should be future-compatible and who knows when your script will end up as part of a package. So we'd see proliferation of the new idiom way beyond necessity, which would be a shame. I'd rather turn the argument around: if you had a main script that used your package before 2.5, the script would be required to use absolute import to access the package anyway. Presumably the script would be copied to somewhere on $PATH and the package would be copied somewhere on $PYTHONPATH (site-packages most likely) and the script would invoke the package via its full name. The new -m feature adds the possibility that exactly the same main script may now also be copied (with the rest of the package) onto $PYTHONPATH, without also copying it to $PATH, and it can be invoked using -m. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On Tue, Jun 27, 2006, Phillip J. Eby wrote: At 08:08 AM 6/27/2006 -0700, Guido van Rossum wrote: Bad idea IMO. The __name__ == __main__ rule is so ingrained, you don't want to mess with it. Actually, maybe we *do* want to, for this usage. Note that until Python 2.5, it was not possible to do python -m nested.module, so this change merely prevents *existing* modules from being run this way -- when they could not have been before! So, such modules would require a minor change to run under -m. Is this actually a problem, or is it a new feature? Well, yes, considering that cd'ing to the module's dir and doing python module.py will now fail. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I saw `cout' being shifted Hello world times to the left and stopped right there. --Steve Gonedes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Guido van Rossum wrote: Bad idea IMO. The __name__ == __main__ rule is so ingrained, you don't want to mess with it. It would only make a difference for main modules inside packages. Wouldn't that be fairly rare? The vast majority of existing __name__ == __main__ uses ought to be unaffected. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Giovanni Bajo wrote: This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. Could this be reconsidered for Py3k? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
On 6/27/06, Greg Ewing [EMAIL PROTECTED] wrote: Giovanni Bajo wrote: This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. Could this be reconsidered for Py3k? You have a point. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
