[Python-Dev] Introduction
Hi I am Shanthkumar from Bangalore, India, working for a software firm. Good to see the mailing group, as i am new to python curious to ask you people couple of queireis. -- Regards..., Shanthkumara O.D. ___ 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] Introduction
On 2012-08-02, at 09:28 , Shanth Kumar wrote: > Hi I am Shanthkumar from Bangalore, India, working for a software firm. > Good to see the mailing group, as i am new to python curious to ask you > people couple of queireis. I fear that is very likely the wrong mailing list for that: python-dev is about the development of the CPython runtime and the language itself, not so much about learning it and developing in it. You probably want python-list (http://mail.python.org/mailman/listinfo/python-list) or tutor (http://mail.python.org/mailman/listinfo/tutor), or your local user group's mailing list (http://mail.python.org/mailman/listinfo/bangpypers) ___ 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] Failed issue tracker submission
There was a problem with the message you sent: This issue can't be closed until issue http://bugs.python.org/issue15502";>15502 is closed. Mail Gateway Help = Incoming messages are examined for multiple parts: . In a multipart/mixed message or part, each subpart is extracted and examined. The text/plain subparts are assembled to form the textual body of the message, to be stored in the file associated with a "msg" class node. Any parts of other types are each stored in separate files and given "file" class nodes that are linked to the "msg" node. . In a multipart/alternative message or part, we look for a text/plain subpart and ignore the other parts. . A message/rfc822 is treated similar tomultipart/mixed (except for special handling of the first text part) if unpack_rfc822 is set in the mailgw config section. Summary --- The "summary" property on message nodes is taken from the first non-quoting section in the message body. The message body is divided into sections by blank lines. Sections where the second and all subsequent lines begin with a ">" or "|" character are considered "quoting sections". The first line of the first non-quoting section becomes the summary of the message. Addresses - All of the addresses in the To: and Cc: headers of the incoming message are looked up among the user nodes, and the corresponding users are placed in the "recipients" property on the new "msg" node. The address in the From: header similarly determines the "author" property of the new "msg" node. The default handling for addresses that don't have corresponding users is to create new users with no passwords and a username equal to the address. (The web interface does not permit logins for users with no passwords.) If we prefer to reject mail from outside sources, we can simply register an auditor on the "user" class that prevents the creation of user nodes with no passwords. Actions --- The subject line of the incoming message is examined to determine whether the message is an attempt to create a new item or to discuss an existing item. A designator enclosed in square brackets is sought as the first thing on the subject line (after skipping any "Fwd:" or "Re:" prefixes). If an item designator (class name and id number) is found there, the newly created "msg" node is added to the "messages" property for that item, and any new "file" nodes are added to the "files" property for the item. If just an item class name is found there, we attempt to create a new item of that class with its "messages" property initialized to contain the new "msg" node and its "files" property initialized to contain any new "file" nodes. Triggers Both cases may trigger detectors (in the first case we are calling the set() method to add the message to the item's spool; in the second case we are calling the create() method to create a new node). If an auditor raises an exception, the original message is bounced back to the sender with the explanatory message given in the exception. Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [IPv6:2001:888:2000:d::a6]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 86BB41CD7E for ; Thu, 2 Aug 2012 13:45:35 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3WnqMM2J6szNbw for ; Thu, 2 Aug 2012 13:45:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1343907935; bh=gCR6sftsrpIrVDajA2ztlOvXtnpd1hd96n2LwhPSZkk=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=eGlIBm9r/zVe4tZZOqtKy8ctuyEEfVHryOb98//t3VAYMgz7Th9wKgpUWNd6OEJnQ hWSOrYKAgNROXrwx+ITyPbwGgMbE1CwRfQiCuxe6RMTQJqoM8kS1MebdE/JiBVrD6U 0h/vjTxlMpKY1YjzbOCqvmuHnaSuTRo3LLieIRRc= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 02 Aug 2012 13:45:35 +0200 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for ; Thu, 2 Aug 2012 13:45:34 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue15519] [status=closed; resolution=fixed; stage=committed/rejected] Message-Id: <[email protected]> Date: Thu, 2 Aug 2012 13:45:35 +0200 (CEST) TmV3IGNoYW5nZXNldCBhMWFjMWUxM2M1YTAgYnkgTmljayBDb2dobGFuIGluIGJyYW5jaCAnZGVm YXVsdCc6CkNsb3NlICMxNTUxOTogUHJvcGVybHkgZXhwb3NlIFdpbmRvd3NSZWdpc3RyeUZpbmRl ciBpbiBpbXBvcnRsaWIgYW5kIGJyaW5nIHRoZSBuYW1lIGludG8gbGluZSB3aXRoIG5vcm1hbCBp bXBvcnQgdGVybWlub2xvZ3kuIE9yaWdpbmFsIHBhdGNoIGJ5IEVyaWMgU25vdwpodHRwOi8vaGcu cHl0aG9uLm9yZy9jcHl0aG9uL3Jldi9hMWFjMW
Re: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the importlib.PathFinder docs and docstring more in line
On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote: >http://hg.python.org/cpython/rev/1f8351cf00f3 >changeset: 78382:1f8351cf00f3 >user:Nick Coghlan >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 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 remem
Re: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the importlib.PathFinder docs and docstring more in line
On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote: > On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote: > >>-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 just say "path" (same with __init__, __main__, etc) and rely on context. --Chris ___ 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] cpython: Issue #15502: Bring the importlib.PathFinder docs and docstring more in line
On Thu, 2 Aug 2012 07:41:05 -0700 Chris Jerdonek wrote: > On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote: > > On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote: > > > >>-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 just say "path" (same with __init__, __main__, etc) and > rely on context. +1. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ 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] [Python-checkins] cpython: Issue #15502: Bring the importlib ABCs into line with the current state of the
Mostly as a note to myself (although if someone else wants to change this, then great), PathEntryFinder.find_loader() specifies self while the other docs don't bother to list it. And I just realized that the other classes defined in the importlib docs don't list their superclasses like MetaPathFinder and PathEntryFinder now do. On Thu, Aug 2, 2012 at 7:26 AM, nick.coghlan wrote: > http://hg.python.org/cpython/rev/184700df5b6a > changeset: 78379:184700df5b6a > parent: 78376:8ace059cdffd > user:Nick Coghlan > date:Thu Aug 02 21:26:03 2012 +1000 > summary: > Issue #15502: Bring the importlib ABCs into line with the current state > of the import protocols given PEP 420. Original patch by Eric Snow. > > files: > Doc/library/importlib.rst | 77 +--- > Lib/importlib/abc.py | 82 ++--- > Lib/test/test_importlib/source/test_abc_loader.py | 23 +- > Lib/test/test_importlib/test_abc.py | 7 +- > Misc/NEWS | 3 + > 5 files changed, 127 insertions(+), 65 deletions(-) > > > diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst > --- a/Doc/library/importlib.rst > +++ b/Doc/library/importlib.rst > @@ -125,32 +125,49 @@ > > .. class:: Finder > > -An abstract base class representing a :term:`finder`. > -See :pep:`302` for the exact definition for a finder. > - > -.. method:: find_loader(self, fullname): > - > -An abstract method for finding a :term:`loader` for the specified > -module. Returns a 2-tuple of ``(loader, portion)`` where portion > is a > -sequence of file system locations contributing to part of a > namespace > -package. The sequence may be empty. When present, > `find_loader()` is > -preferred over `find_module()`. > - > -.. versionadded: 3.3 > - > -.. method:: find_module(fullname, path=None) > - > -An abstract method for finding a :term:`loader` for the specified > -module. If the :term:`finder` is found on :data:`sys.meta_path` > and the > -module to be searched for is a subpackage or module then *path* > will > -be the value of :attr:`__path__` from the parent package. If a > loader > -cannot be found, ``None`` is returned. > + An abstract base class representing a :term:`finder`. Finder > + implementations should derive from (or register with) the more specific > + :class:`MetaPathFinder` or :class:`PathEntryFinder` ABCs. > > .. method:: invalidate_caches() > > -An optional method which, when called, should invalidate any > internal > -cache used by the finder. Used by :func:`invalidate_caches()` when > -invalidating the caches of all cached finders. > + An optional method which, when called, should invalidate any > internal > + cache used by the finder. Used by :func:`invalidate_caches()` when > + invalidating the caches of all cached finders. > + > + .. versionchanged:: 3.3 > + The API signatures for meta path finders and path entry finders > + were separated by PEP 420. Accordingly, the Finder ABC no > + longer requires implementation of a ``find_module()`` method. > + > + > +.. class:: MetaPathFinder(Finder) > + > + An abstract base class representing a :term:`meta path finder`. > + > + .. versionadded:: 3.3 > + > + .. method:: find_module(fullname, path) > + > + An abstract method for finding a :term:`loader` for the specified > + module. If this is a top-level import, *path* will be ``None``. > + Otheriwse, this is a search for a subpackage or module and *path* > + will be the value of :attr:`__path__` from the parent > + package. If a loader cannot be found, ``None`` is returned. > + > + > +.. class:: PathEntryFinder(Finder) > + > + An abstract base class representing a :term:`path entry finder`. > + > + .. versionadded:: 3.3 > + > + .. method:: find_loader(self, fullname): > + > + An abstract method for finding a :term:`loader` for the specified > + module. Returns a 2-tuple of ``(loader, portion)`` where portion > is a > + sequence of file system locations contributing to part of a > namespace > + package. The sequence may be empty. > > > .. class:: Loader > @@ -569,8 +586,8 @@ > > An :term:`importer` for built-in modules. All known built-in modules > are > listed in :data:`sys.builtin_module_names`. This class implements the > -:class:`importlib.abc.Finder` and :class:`importlib.abc.InspectLoader` > -ABCs. > +:class:`importlib.abc.MetaPathFinder` and > +:class:`importlib.abc.InspectLoader` ABCs. > > Only class methods are defined by this class to alleviate the need for > instantiation. > @@ -579,8 +596,8 @@ > .. class:: FrozenImporter > > An :term:`importer` for frozen modules. This class implements the > -:class:`importlib.abc.Finder` and :class:`imp
Re: [Python-Dev] PEP 0424: A method for exposing a length hint
On Aug 1, 2012, at 1:46 AM, Mark Shannon wrote: > > ''' > Being able to pre-allocate lists based on the expected size, as estimated by > __length_hint__, > can be a significant optimization. > PyPy has been observed to run some code slower than CPython, purely because > this optimization is absent. > ''' > > Which is a PyPy bug report, not a rationale for a PEP ;) Alex's rationale is correct and well expressed. Your proposed revision reflects fuzzy thinking about why __length_hint__ is useful. Regardless of resizing growth factors, it is *always* helpful to know how much memory to allocate. Calls to the allocators (especially for large blocks) and possible the recopying of data should be avoided when possible. Raymond___ 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] [Python-checkins] cpython: Issue #15502: Bring the importlib.PathFinder docs and docstring more in line
Chris Jerdonek writes: > On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote: > > I find this change hilarious! Is it "an under-under path" or "a > > dunder path"? > > Personally, I just say "path" (same with __init__, __main__, etc) and > rely on context. I think that's what the Chicago Manual of Style recommends. Now-needing-surgery-for-my-cheek-hernia-ly y'rs, ___ 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] [Python-checkins] cpython: Update the What's New details for importlib based on doc/ABC changes.
Sorry about accidentally committing another minor cleanup to importlib in this commit; thought I had already committed it separately. On Thu, Aug 2, 2012 at 5:50 PM, brett.cannon wrote: > http://hg.python.org/cpython/rev/083534cd7874 > changeset: 78388:083534cd7874 > user:Brett Cannon > date:Thu Aug 02 17:50:06 2012 -0400 > summary: > Update the What's New details for importlib based on doc/ABC changes. > > files: > Doc/library/importlib.rst | 10 ++ > Doc/whatsnew/3.3.rst | 24 +++- > 2 files changed, 25 insertions(+), 9 deletions(-) > > > diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst > --- a/Doc/library/importlib.rst > +++ b/Doc/library/importlib.rst > @@ -141,9 +141,10 @@ >longer requires implementation of a ``find_module()`` method. > > > -.. class:: MetaPathFinder(Finder) > +.. class:: MetaPathFinder > > - An abstract base class representing a :term:`meta path finder`. > + An abstract base class representing a :term:`meta path finder` and > + inheriting from :class:`Finder`. > > .. versionadded:: 3.3 > > @@ -156,9 +157,10 @@ >package. If a loader cannot be found, ``None`` is returned. > > > -.. class:: PathEntryFinder(Finder) > +.. class:: PathEntryFinder > > - An abstract base class representing a :term:`path entry finder`. > + An abstract base class representing a :term:`path entry finder` and > + inheriting from :class:`Finder`. > > .. versionadded:: 3.3 > > diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst > --- a/Doc/whatsnew/3.3.rst > +++ b/Doc/whatsnew/3.3.rst > @@ -519,7 +519,15 @@ > making the import statement work. That means the various importers that > were > once implicit are now fully exposed as part of the :mod:`importlib` > package. > > -In terms of finders, * :class:`importlib.machinery.FileFinder` exposes the > +The abstract base classes defined in :mod:`importlib.abc` have been > expanded > +to properly delineate between :term:`meta path finders ` > +and :term:`path entry finders ` by introducing > +:class:`importlib.abc.MetaPathFinder` and > +:class:`importlib.abc.PathEntryFinder`, respectively. The old ABC of > +:class:`importlib.abc.Finder` is now only provided for > backwards-compatibility > +and does not enforce any method requirements. > + > +In terms of finders, :class:`importlib.machinery.FileFinder` exposes the > mechanism used to search for source and bytecode files of a module. > Previously > this class was an implicit member of :attr:`sys.path_hooks`. > > @@ -547,10 +555,10 @@ > > Beyond the expanse of what :mod:`importlib` now exposes, there are other > visible changes to import. The biggest is that :attr:`sys.meta_path` and > -:attr:`sys.path_hooks` now store all of the finders used by import > explicitly. > -Previously the finders were implicit and hidden within the C code of > import > -instead of being directly exposed. This means that one can now easily > remove or > -change the order of the various finders to fit one's needs. > +:attr:`sys.path_hooks` now store all of the meta path finders and path > entry > +hooks used by import. Previously the finders were implicit and hidden > within > +the C code of import instead of being directly exposed. This means that > one can > +now easily remove or change the order of the various finders to fit one's > needs. > > Another change is that all modules have a ``__loader__`` attribute, > storing the > loader used to create the module. :pep:`302` has been updated to make this > @@ -1733,6 +1741,12 @@ >both the modification time and size of the source file the bytecode > file was >compiled from. > > +* :class:`importlib.abc.Finder` no longer specifies a `find_module()` > abstract > + method that must be implemented. If you were relying on subclasses to > + implement that method, make sure to check for the method's existence > first. > + You will probably want to check for `find_loader()` first, though, in > the > + case of working with :term:`path entry finders `. > + > * :mod:`pkgutil` has been converted to use :mod:`importlib` internally. > This >eliminates many edge cases where the old behaviour of the PEP 302 import >emulation failed to match the behaviour of the real import system. The > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > > ___ 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] [Python-checkins] cpython: Issue #15502: Bring the importlib.PathFinder docs and docstring more in line
On Fri, Aug 3, 2012 at 12:41 AM, Chris Jerdonek wrote: > On Thu, Aug 2, 2012 at 7:32 AM, Barry Warsaw wrote: >> On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote: >> >>>-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 just say "path" (same with __init__, __main__, etc) and > rely on context. Yup. That's why I would write "a __path__ attribute", but "an __init__ method". If I have to be explicit when speaking, I'll typically say either "dunder " or "double underscore ". I find that's only needed if there is a name class between the double underscore name and a non-prefixed variable though, which doesn't happen very often. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
