Re: [Python-Dev] Adding NetworkIOError for bug 1706815
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. 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. 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). -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. > 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. ___ 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] Tracker item: 735515 - urllib to cache 301 redirections?
Hi, One of the tracker items: 735515 mentions that urllib should cache 301 and 302 redirections. urllib / urllib2 should cache the results of 301 (permanent) redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC (2616, section 10.3.2, first para) says SHOULD happen. I am trying to understand, what does it mean. Should the original url be avaiable to the user upon request as urllib automatically calls the redirect_request and provides the redirected url only? I am not completely getting what "cache - redirection" implies and what should be done with the urllib2 module. Any pointers? Thanks, -- O.R.Senthil Kumaran http://uthcode.sarovar.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
[Python-Dev] PEP 366 - Relative imports from main modules
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 enhancements described in PEP 338 for Python 2.5. The philosophy that motivated those previous additions (i.e. access to utility or testing scripts without needing to worry about name clashes in either the OS executable namespace or the top level Python namespace) is also the motivation behind fixing what I see as a bug in the current implementation. This PEP is intended to provide a solution which permits explicit relative imports from main modules, without incurring any significant costs during interpreter startup or normal module import. Proposed Solution = The heart of the proposed solution is a new module attribute ``__package_name__``. This attribute will be defined only in the main module (i.e. modules wh
Re: [Python-Dev] Adding NetworkIOError for bug 1706815
On Tue, 3 Jul 2007 23:58:44 -0700, "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 > FWIW, that page does not seem to be generally accessible. It's difficult to know what you're talking about without being able to see it. Artifact: Invalid ArtifactID; this Tracker item may have moved to a different Tracker since this URL was generated -- [Find the new location of this Tracker item] Following [Find the new location ...]: Artifact: This Artifact Has Been Made Private. Only Group Members Can View Private ArtifactTypes. >Any thoughts? I'm happy with it and would like to commit it if folks >agree. > Jean-Paul ___ 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] Adding NetworkIOError for bug 1706815
Why not simply inherit socket.error from EnvironmentError? 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. > > ___ > 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/guido%40python.org > -- --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
[Python-Dev] Adding NetworkIOError for bug 1706815
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. ___ 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
