Mailman 3 August 2012 - Python-Dev

PEP 366 is unclear about what it specifies
by Stefan Behnel Aug. 7, 2012

Aug. 7, 2012

Hi, could someone please add a sentence to PEP 366 that describes the actual content of the new "__package__" attribute (and thus, the PEP)? http://www.python.org/dev/peps/pep-0366/ I had to read through almost the entire document to be assured that "__package__" is really supposed to contain a string and I had a hard time nailing down its content. The only real hint in there is the example, and even that is ambiguous. Please change the first paragraph in the "proposed change" section to … [View More]

4 3

yield from, user defined iterators, and StopIteration w/ a value...
by Dino Viehland Aug. 6, 2012

Aug. 6, 2012

I'm trying to create an object which works like a generator and delegates to a generator for its implementation, but can also participate in yield from using 3.3 beta. I want my wrapper object to be able to cache some additional information - such as whether or not the generator has completed - as well as have it provide some additional methods for interacting with the state of the generator. But currently this doesn't seem possible because raising StopIteration from a user defined iterator … [View More]

3 2

No summary of tracker issues this week?
by Mark Lawrence Aug. 5, 2012

Aug. 5, 2012

Hi all, I keep an eye open for this but can't find one for Saturday 03/08/2012. Have I missed it, has it been stopped, has something gone wrong with its production or what? -- Cheers. Mark Lawrence.

3 2

Summary of Python tracker Issues
by Python tracker Aug. 5, 2012

Aug. 5, 2012

ACTIVITY SUMMARY (2012-07-30 - 2012-08-06) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 3559 (+18) closed 23781 (+51) total 27340 (+69) Open issues with patches: 1534 Issues opened (42) ================== #13072: Getting a buffer from a Unicode array uses invalid format http://bugs.python.org/issue13072 reopened by haypo #15494: Move test/… [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): Make TextIOWrapper's documentation clearer by copying the newline argument's
by Chris Jerdonek Aug. 5, 2012

Aug. 5, 2012

On Fri, Aug 3, 2012 at 3:59 PM, antoine.pitrou <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/f17a1410ebe5 > changeset: 78401:f17a1410ebe5 > summary: > Make TextIOWrapper's documentation clearer by copying the newline argument's description from open(). Now that this change is made, it may make sense to update the subprocess documentation to reference TextIOWrapper's documentation instead of open()'s (since use of the 'U' flag to open() is … [View More]

2 2

Re: [Python-Dev] [Python-checkins] devguide: It has been pointed out this paragraph was incorrect. One of the Windows devs
by Chris Jerdonek Aug. 5, 2012

Aug. 5, 2012

On Sun, Aug 5, 2012 at 1:48 AM, nick.coghlan <python-checkins(a)python.org> wrote: > http://hg.python.org/devguide/rev/f518f23d06d5 > changeset: 539:f518f23d06d5 > summary: > It has been pointed out this paragraph was incorrect. One of the Windows devs will need to fill in more accurate info > diff --git a/setup.rst b/setup.rst > -For Windows systems, all the necessary components should be included in the > -CPython checkout. This issue may not provide the … [View More]

1 0

Re: [Python-Dev] cpython: Close #15559: Implementing __index__ creates a nasty interaction with the bytes
by Antoine Pitrou Aug. 5, 2012

Aug. 5, 2012

On Sun, 5 Aug 2012 10:20:36 +0200 (CEST) nick.coghlan <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/5abea8a43f19 > changeset: 78426:5abea8a43f19 > user: Nick Coghlan <ncoghlan(a)gmail.com> > date: Sun Aug 05 18:20:17 2012 +1000 > summary: > Close #15559: Implementing __index__ creates a nasty interaction with the bytes constructor. At least for 3.3, ipaddress objects must now be explicitly converted with int() and thus … [View More]

2 1

issue 15510: textwrap.wrap() returning empty list
by Chris Jerdonek Aug. 3, 2012

Aug. 3, 2012

I would like people's opinions on issue 15510, specifically whether it should be addressed and in what versions: http://bugs.python.org/issue15510 Jesús suggested that I ask. The issue relates to textwrap.wrap()'s behavior when wrapping strings that contain no non-whitespace characters -- in particular the empty string. Thanks, --Chris

2 1

Question
by Dheeraj Goswami Aug. 3, 2012

Aug. 3, 2012

Hi Python Gurus, I am an experienced Java developer and have been working on it for about 8 years. I need to build a web 2.0/AJAX based website/application and I am thinking to build it in Django which means I need to learn and move to Python. Please advise is it really worth moving from Java world into Python world? Will it really be fun to build in Django. PS: I dont like magics so I will never use Ruby/Rails as I am not that kind of guy. cheers /Dg

3 2

Re: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the importlib.PathFinder docs and docstring more in line
by Barry Warsaw Aug. 3, 2012

Aug. 3, 2012

On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote: >http://hg.python.org/cpython/rev/1f8351cf00f3 >changeset: 78382:1f8351cf00f3 >user: Nick Coghlan <ncoghlan(a)gmail.com> >date: Thu Aug 02 23:03:58 2012 +1000 >summary: > Issue #15502: Bring the importlib.PathFinder docs and docstring more in line with the new import system documentation, and fix various parts of the new docs that weren't quite right given PEP 420 or were otherwise a bit misleading. Also … [View More]note the key terminology problem still being discussed in the issue > >files: > Doc/library/importlib.rst | 15 +- > Doc/reference/import.rst | 221 +- > Lib/importlib/_bootstrap.py | 8 +- > Python/importlib.h | 2583 +++++++++++----------- > 4 files changed, 1449 insertions(+), 1378 deletions(-) > > >diff --git a/Doc/reference/import.rst b/Doc/reference/import.rst >--- a/Doc/reference/import.rst >+++ b/Doc/reference/import.rst >@@ -69,7 +75,7 @@ > > It's important to keep in mind that all packages are modules, but not all > modules are packages. Or put another way, packages are just a special kind of >-module. Specifically, any module that contains an ``__path__`` attribute is >+module. Specifically, any module that contains a ``__path__`` attribute is I find this change hilarious! Is it "an under-under path" or "a dunder path"? Personally, I think word "dunder" should never be used unless it's followed by the word "mifflin", but that might be a bit too regional. Or maybe too old skool (yeah, I know all the kids love the dunder). I suppose I don't care that much, but it would be useful to have some consistency, like whether we use American or British spellings. >@@ -90,7 +96,7 @@ > packages are traditional packages as they existed in Python 3.2 and earlier. > A regular package is typically implemented as a directory containing an > ``__init__.py`` file. When a regular package is imported, this >-``__init__.py`` file is implicitly imported, and the objects it defines are >+``__init__.py`` file is implicitly executed, and the objects it defines are Perhaps "loaded" instead of either "imported" or "executed"? >@@ -107,9 +113,9 @@ > three/ > __init__.py > >-Importing ``parent.one`` will implicitly import ``parent/__init__.py`` and >+Importing ``parent.one`` will implicitly execute ``parent/__init__.py`` and Same. > ``parent/one/__init__.py``. Subsequent imports of ``parent.two`` or >-``parent.three`` will import ``parent/two/__init__.py`` and >+``parent.three`` will execute ``parent/two/__init__.py`` and And here. > ``parent/three/__init__.py`` respectively. > > >@@ -128,6 +134,12 @@ > objects on the file system; they may be virtual modules that have no concrete > representation. > >+Namespace packages do not use an ordinary list for their ``__path__`` >+attribute. They instead use a custom iterable type which will automatically >+perform a new search for package portions on the next import attempt within >+that package if the path of their parent package (or :data:`sys.path` for a >+top level package) changes. Nice addition. I can't help but suggest a slight rephrasing: Namespace packages use a custom iterable type for their ``__path__`` attribute, so that changes in their parent package's path (or :data:`sys.path` for a top level package) are handled automatically. >@@ -172,14 +184,18 @@ > :exc:`ImportError` is raised. If the module name is missing, Python will > continue searching for the module. > >-:data:`sys.modules` is writable. Deleting a key will not destroy the >-associated module, but it will invalidate the cache entry for the named >-module, causing Python to search anew for the named module upon its next >-import. Beware though, because if you keep a reference to the module object, >+:data:`sys.modules` is writable. Deleting a key may not destroy the >+associated module (as other modules may hold references to it), s/as other modules may hold references to it/due to circular references/ >@@ -369,7 +404,7 @@ > > Here are the exact rules used: > >- * If the module has an ``__loader__`` and that loader has a >+ * If the module has a ``__loader__`` and that loader has a > :meth:`module_repr()` method, call it with a single argument, which is the > module object. The value returned is used as the module's repr. > >@@ -377,10 +412,10 @@ > and discarded, and the calculation of the module's repr continues as if > :meth:`module_repr()` did not exist. > >- * If the module has an ``__file__`` attribute, this is used as part of the >+ * If the module has a ``__file__`` attribute, this is used as part of the > module's repr. > >- * If the module has no ``__file__`` but does have an ``__loader__``, then the >+ * If the module has no ``__file__`` but does have a ``__loader__``, then the > loader's repr is used as part of the module's repr. > > * Otherwise, just use the module's ``__name__`` in the repr. C'mon Michael Scott, make it stop! Do you remember the episode where Dwight and Jim team up to... Oh, I was in stitches! >@@ -430,15 +467,20 @@ > path`, which contains a list of :term:`path entries <path entry>`. Each path > entry names a location to search for modules. > >-Path entries may name file system locations, and by default the :term:`path >-importer` knows how to provide traditional file system imports. It implements >-all the semantics for finding modules on the file system, handling special >-file types such as Python source code (``.py`` files), Python byte code >-(``.pyc`` and ``.pyo`` files) and shared libraries (e.g. ``.so`` files). >+The path importer itself doesn't know how to import anything. Instead, it >+traverses the individual path entries, associating each of them with a >+path entry finder that knows how to handle that particular kind of path. >+ >+The default set of path entry finders implement all the semantics for finding >+modules on the file system, handling special file types such as Python source >+code (``.py`` files), Python byte code (``.pyc`` and ``.pyo`` files) and >+shared libraries (e.g. ``.so`` files). When supported by the :mod:`zipimport` >+module in the standard library, the default path entry finders also handle >+loading all of these file types (other than shared libraries) from zipfiles. s/zipfiles/zip files/ > > Path entries need not be limited to file system locations. They can refer to >-the contents of zip files, URLs, database queries, or any other location that >-can be specified as a string. >+the URLs, database queries, or any other location that can be specified as a >+string. s/the URLs/URLs/ > > The :term:`path importer` provides additional hooks and protocols so that you > can extend and customize the types of searchable path entries. For example, >@@ -534,29 +578,59 @@ > Path entry finder protocol > -------------------------- > >-Path entry finders support the same :meth:`find_module()` method that meta >-path finders support, however path entry finder's :meth:`find_module()` >-methods are never called with a ``path`` argument. >- >-The :meth:`find_module()` method on path entry finders is deprecated though, >-and instead path entry finders should implement the :meth:`find_loader()` >-method. If it exists on the path entry finder, :meth:`find_loader()` will >-always be called instead of :meth:`find_module()`. >+In order to support imports of modules and initialized packages and also to >+contribute portions to namespace packages, path entry finders must implement >+the :meth:`find_loader()` method. This is an improvement, because it de-emphasizes the deprecated API. Perhaps add a footnote that describes the legacy API? > :meth:`find_loader()` takes one argument, the fully qualified name of the > module being imported. :meth:`find_loader()` returns a 2-tuple where the > first item is the loader and the second item is a namespace :term:`portion`. > When the first item (i.e. the loader) is ``None``, this means that while the >-path entry finder does not have a loader for the named module, it knows that >-the :term:`path entry` contributes to a namespace portion for the named >-module. This will almost always be the case where Python is asked to import a >-:term:`namespace package` that has no physical presence on the file system. >-When a path entry finder returns ``None`` for the loader, the second item of >-the 2-tuple return value must be a sequence, although it can be empty. >+path entry finder does not have a loader for the named module, it knows that the >+path entry contributes to a namespace portion for the named module. This will >+almost always be the case where Python is asked to import a namespace package >+that has no physical presence on the file system. When a path entry finder >+returns ``None`` for the loader, the second item of the 2-tuple return value >+must be a sequence, although it can be empty. > > If :meth:`find_loader()` returns a non-``None`` loader value, the portion is >-ignored and the loader is returned from the :term:`path importer`, terminating >-the :term:`import path` search. >+ignored and the loader is returned from the path importer, terminating the >+search through the path entries. >+ >+For backwards compatibility with other implementations of the import >+protocol, many path entry finders also support the same, >+traditional :meth:`find_module()` method that meta path finders support. >+However path entry finder :meth:`find_module()` methods are never called >+with a ``path`` argument (they are expected to record the appropriate >+path information from the initial call to the path hook). >+ >+The :meth:`find_module()` method on path entry finders is deprecated, >+as it does not allow the path entry finder to contribute portions to >+namespace packages. Instead path entry finders should implement the >+:meth:`find_loader()` method as described above. If it exists on the path >+entry finder, the import system will always call :meth:`find_loader()` >+in preference to :meth:`find_module()`. The above is what could be moved to the footnote. Cheers, -Barry [View Less]

5 4