Re: [Python-Dev] PEP 366 - Relative imports from main modules
I see no big problems with this, except I wonder if in the end it wouldn't be better to *always* define __package_name__ instead of only when it's in main? And then perhaps rename it to __package__? Done properly it could always be used for relative imports, rather than parsing __module__ to find the package. Then you won't even need the error handler. FWIW, I find the PEP is rather wordy for such a simple proposal (it took me more time to find the proposal than to understand it :-). --Guido On 7/4/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > A c.l.p discussion referenced from Python-URL just brought this topic > back to my attention, and with the relatively low traffic on the > development lists in the last few days, it seemed like a good time to > repost this PEP (it vanished beneath the Unicode identifier discussion > last time). > > Cheers, > Nick. > > > PEP: 366 > Title: Main module explicit relative imports > Version: $Revision: 56172 $ > Last-Modified: $Date: 2007-07-04 22:47:13 +1000 (Wed, 04 Jul 2007) $ > Author: Nick Coghlan <[EMAIL PROTECTED]> > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 1-May-2007 > Python-Version: 2.6 > Post-History: 1-May-2007 > > > Abstract > > > This PEP proposes a backwards compatible mechanism that permits > the use of explicit relative imports from executable modules within > packages. Such imports currently fail due to an awkward interaction > between PEP 328 and PEP 338 - this behaviour is the subject of at > least one open SF bug report (#1510172)[1], and has most likely > been a factor in at least a few queries on comp.lang.python (such > as Alan Isaac's question in [2]). > > With the proposed mechanism, relative imports will work automatically > if the module is executed using the ``-m`` switch. A small amount of > boilerplate will be needed in the module itself to allow the relative > imports to work when the file is executed by name. > > > Import Statements and the Main Module > = > > (This section is taken from the final revision of PEP 338) > > The release of 2.5b1 showed a surprising (although obvious in > retrospect) interaction between PEP 338 and PEP 328 - explicit > relative imports don't work from a main module. This is due to > the fact that relative imports rely on ``__name__`` to determine > the current module's position in the package hierarchy. In a main > module, the value of ``__name__`` is always ``'__main__'``, so > explicit relative imports will always fail (as they only work for > a module inside a package). > > Investigation into why implicit relative imports *appear* to work when > a main module is executed directly but fail when executed using ``-m`` > showed that such imports are actually always treated as absolute > imports. Because of the way direct execution works, the package > containing the executed module is added to sys.path, so its sibling > modules are actually imported as top level modules. This can easily > lead to multiple copies of the sibling modules in the application if > implicit relative imports are used in modules that may be directly > executed (e.g. test modules or utility scripts). > > For the 2.5 release, the recommendation is to always use absolute > imports in any module that is intended to be used as a main module. > The ``-m`` switch already provides a benefit here, as it inserts the > current directory into ``sys.path``, instead of the directory containing > the main module. This means that it is possible to run a module from > inside a package using ``-m`` so long as the current directory contains > the top level directory for the package. Absolute imports will work > correctly even if the package isn't installed anywhere else on > sys.path. If the module is executed directly and uses absolute imports > to retrieve its sibling modules, then the top level package directory > needs to be installed somewhere on sys.path (since the current directory > won't be added automatically). > > Here's an example file layout:: > > devel/ > pkg/ > __init__.py > moduleA.py > moduleB.py > test/ > __init__.py > test_A.py > test_B.py > > So long as the current directory is ``devel``, or ``devel`` is already > on ``sys.path`` and the test modules use absolute imports (such as > ``import pkg.moduleA`` to retrieve the module under test, PEP 338 > allows the tests to be run as:: > > python -m pkg.test.test_A > python -m pkg.test.test_B > > Rationale for Change > > > In rejecting PEP 3122 (which proposed a higher impact solution to this > problem), Guido has indicated that he still isn't particularly keen on > the idea of executing modules inside packages as scripts [2]. Despite > these misgivings he has previously approved the addition of the ``-m`` > switch in Python 2.4, and the ``runpy`` module based enha
Re: [Python-Dev] Adding NetworkIOError for bug 1706815
On 7/5/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > On Wed, Jul 04, 2007 at 11:03:42AM +0200, Guido van Rossum wrote: > > Why not simply inherit socket.error from EnvironmentError? > > True, that would be simpler; is it enough? If we avoid adding the new > exception, I really think it should inherit from IOError, not > EnviromnentError because sockets are I/O. urllib2.URLError was > already a child of IOError; doing the same to to socket.error makes > sense. OTOH, when os.read() returns an error, os.error (OSError) is raised. Is that not I/O? IMO this is all hairsplitting, and the exact inheritance hierarchy for these doesn't matter much -- nobody is going to write a handler that treats OSError or socket.error different than IOError. (If you have different call sites that raise different exceptions, each call site should have a separate try/except rather than a single try/except with multiple handlers.) > The patch makes URLError a child of NetworkIOError instead of IOError. > Does that make sense? URLs as an abstract concept may or may not > imply network I/O behind the scenes though network i/o is the most > common use. I could take that argument further and suggest they don't > necessarily even imply actual I/O if you've provided your own protocol > handlers. Well, as long as NetworkIOError inherits from IOError, the change is compatible, but I don't think anyone would care. Making URLError a child of EnvironmentError or socket.error could be defended too, and I doubt it makes a difference for any real code. (Anyone with evidence to the contrary, please speak up now). > The question then becomes if there are any use cases for "except > NetworkIOError:" that code wouldn't want to just use "except IOError:" > for that using "except socket.error:" or "except urllib2.URLError:" > are insufficient for. My intuition is telling me: probably not. > urllib2 code should catch socket.error everywhere internally and turn > it into a URLError (the code appears to do this in many places though > i haven't audited that it does everywhere). Hm. I'm no fan of such renaming of exceptions (even though the __cause__ mechanism from PEP 3134 (formerly 344) makes it a little less problematic). > -greg > > PS for the person complaining that the url didn't work. blame >sourceforge and go look the bug up by id yourself. nothing i can >do about that. Try python.org/sf/1706815 --Guido > > On 7/4/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > >In response to bug 1706815 and seeing messy code to catch errors in > > >network apps I've implemented most of the ideas in the bug and added a > > >NetworkIOError exception (child of IOError). With this, socket.error > > >would now inherit from NetworkIOError instead of being its own thing > > >(the old one didn't even declare a parent!). > > > > > >Complete patch attached to the bug. All unit tests pass. > > >Documentation updates included. > > > > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1706816&group_id=5470&atid=105470 > > > > > >Any thoughts? I'm happy with it and would like to commit it if folks > > >agree. > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 366 - Relative imports from main modules
Oh, one more thing. Perhaps we should rename it, like the other PEPs still active slated for inclusion in Py3k (and backporting to 2.6)? --Guido On 7/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I see no big problems with this, except I wonder if in the end it > wouldn't be better to *always* define __package_name__ instead of only > when it's in main? And then perhaps rename it to __package__? Done > properly it could always be used for relative imports, rather than > parsing __module__ to find the package. Then you won't even need the > error handler. > > FWIW, I find the PEP is rather wordy for such a simple proposal (it > took me more time to find the proposal than to understand it :-). > > --Guido > > On 7/4/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > A c.l.p discussion referenced from Python-URL just brought this topic > > back to my attention, and with the relatively low traffic on the > > development lists in the last few days, it seemed like a good time to > > repost this PEP (it vanished beneath the Unicode identifier discussion > > last time). > > > > Cheers, > > Nick. > > > > > > PEP: 366 > > Title: Main module explicit relative imports > > Version: $Revision: 56172 $ > > Last-Modified: $Date: 2007-07-04 22:47:13 +1000 (Wed, 04 Jul 2007) $ > > Author: Nick Coghlan <[EMAIL PROTECTED]> > > Status: Draft > > Type: Standards Track > > Content-Type: text/x-rst > > Created: 1-May-2007 > > Python-Version: 2.6 > > Post-History: 1-May-2007 > > > > > > Abstract > > > > > > This PEP proposes a backwards compatible mechanism that permits > > the use of explicit relative imports from executable modules within > > packages. Such imports currently fail due to an awkward interaction > > between PEP 328 and PEP 338 - this behaviour is the subject of at > > least one open SF bug report (#1510172)[1], and has most likely > > been a factor in at least a few queries on comp.lang.python (such > > as Alan Isaac's question in [2]). > > > > With the proposed mechanism, relative imports will work automatically > > if the module is executed using the ``-m`` switch. A small amount of > > boilerplate will be needed in the module itself to allow the relative > > imports to work when the file is executed by name. > > > > > > Import Statements and the Main Module > > = > > > > (This section is taken from the final revision of PEP 338) > > > > The release of 2.5b1 showed a surprising (although obvious in > > retrospect) interaction between PEP 338 and PEP 328 - explicit > > relative imports don't work from a main module. This is due to > > the fact that relative imports rely on ``__name__`` to determine > > the current module's position in the package hierarchy. In a main > > module, the value of ``__name__`` is always ``'__main__'``, so > > explicit relative imports will always fail (as they only work for > > a module inside a package). > > > > Investigation into why implicit relative imports *appear* to work when > > a main module is executed directly but fail when executed using ``-m`` > > showed that such imports are actually always treated as absolute > > imports. Because of the way direct execution works, the package > > containing the executed module is added to sys.path, so its sibling > > modules are actually imported as top level modules. This can easily > > lead to multiple copies of the sibling modules in the application if > > implicit relative imports are used in modules that may be directly > > executed (e.g. test modules or utility scripts). > > > > For the 2.5 release, the recommendation is to always use absolute > > imports in any module that is intended to be used as a main module. > > The ``-m`` switch already provides a benefit here, as it inserts the > > current directory into ``sys.path``, instead of the directory containing > > the main module. This means that it is possible to run a module from > > inside a package using ``-m`` so long as the current directory contains > > the top level directory for the package. Absolute imports will work > > correctly even if the package isn't installed anywhere else on > > sys.path. If the module is executed directly and uses absolute imports > > to retrieve its sibling modules, then the top level package directory > > needs to be installed somewhere on sys.path (since the current directory > > won't be added automatically). > > > > Here's an example file layout:: > > > > devel/ > > pkg/ > > __init__.py > > moduleA.py > > moduleB.py > > test/ > > __init__.py > > test_A.py > > test_B.py > > > > So long as the current directory is ``devel``, or ``devel`` is already > > on ``sys.path`` and the test modules use absolute imports (such as > > ``import pkg.moduleA`` to retrieve the module under test, PEP 338 > > allows the tests to be run as:: > > > > python -m pkg.test.test_A > > python -m
[Python-Dev] IDLE Functionality
Hi, I am trying to duplicate the indenting functionality of the IDLE into another environment used in an educational setting at MIT. As Python is open software, I assume I can look at the source code for the IDLE. If someone could kindly give me a pointer as to where I might find the source code for this functionality, I would very much appreciate it. Thank you very much, Beth___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] csv changed from python 2.4 to 2.5
Nick Craig-Wood wrote: > Christian K <[EMAIL PROTECTED]> wrote: [...] >> Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) >> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. > import csv > d = csv.excel > d.delimiter = ',' > > > Don't you want to do this anyway? > > import csv > class my_dialect(csv.excel): > delimeter = "," > I could probably do that, sure. I used to register my custom dialects and retrieve and modify them at another place, thus probably misusing the register mechanism as a replacement for a global symbol. Thanks, Christian ___ Python-Dev mailing list [email protected] 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 366 - Relative imports from main modules
Guido van Rossum wrote: > Oh, one more thing. Perhaps we should rename it, like the other PEPs > still active slated for inclusion in Py3k (and backporting to 2.6)? Might as well be consistent - I'll take care of that when I update the PEP based on your suggestions. > On 7/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> I see no big problems with this, except I wonder if in the end it >> wouldn't be better to *always* define __package_name__ instead of only >> when it's in main? And then perhaps rename it to __package__? Done >> properly it could always be used for relative imports, rather than >> parsing __module__ to find the package. Then you won't even need the >> error handler. I'll have a look at what would be involved in always defining __package__ and using it for relative imports. I suspect it will be a slightly bigger change than the current PEP (i.e. more lines/files touched), but not significantly so. >> FWIW, I find the PEP is rather wordy for such a simple proposal (it >> took me more time to find the proposal than to understand it :-). Yeah, I still haven't come up with a particularly concise way of explaining why relative imports don't currently work in main modules. I'll rearrange the PEP to put the proposed fix before the detailed explanation of the problem (in fact, given that the latter is mainly of historical interest now, I may just include a pointer to the relevant section of PEP 338). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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 366 - Relative imports from main modules
At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote: >I see no big problems with this, except I wonder if in the end it >wouldn't be better to *always* define __package_name__ instead of only >when it's in main? And then perhaps rename it to __package__? Done >properly it could always be used for relative imports, rather than >parsing __module__ to find the package. Then you won't even need the >error handler. +1 for __package__, and putting it everywhere. Relative import should use it first if present, falling back to use of __name__. ___ Python-Dev mailing list [email protected] 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 366 - Relative imports from main modules
On 7/5/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote: > >I see no big problems with this, except I wonder if in the end it > >wouldn't be better to *always* define __package_name__ instead of only > >when it's in main? And then perhaps rename it to __package__? Done > >properly it could always be used for relative imports, rather than > >parsing __module__ to find the package. Then you won't even need the > >error handler. > > +1 for __package__, and putting it everywhere. Relative import > should use it first if present, falling back to use of __name__. +1 from me as well. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE Functionality
"Oodi Pilzer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi, I am trying to duplicate the indenting functionality of the IDLE into another environment used in an educational setting at MIT. As Python is open software, I assume I can look at the source code for the IDLE. If someone could kindly give me a pointer as to where I might find the source code for this functionality, I would very much appreciate it. After installation, .../Python2.x/Lib/idlelib/*.py are the IDLE source files. For indentation, I would first look in EditorWindow.py. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Error trying to access community buildbot page
When I go to http://www.python.org/dev/buildbot/community/all/ I get a 503 error "Service Temporarily Unavailable". Can anybody shed some light? Thanks, Grig -- http://agiletesting.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
