Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On Fri, May 31, 2013 at 3:13 PM, Chris McDonough chr...@plope.com wrote: On Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote: On 31 maj 2013, at 01:51, Łukasz Langa luk...@langa.pl wrote: Back to the point, though. I don't feel we should complicate the code, tests and documentation by introducing special handling for methods. In terms of pure type-driven single dispatch, we have a solution that was intentionally simple from the get-go. The next step will be predicate dispatch anyway ;)) What do you think? +1. It's incredibly useful and easy to document as-is. Yep, I suggest asking Benjamin for pronouncement - this looks great to me. I should finally be able to clean up the pkgutils.walk_packages docs by explaining how to register new handlers for custom importers :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Problem building Python 2.7.5 with separate sysroot
Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14) system, but using a different sysroot (that is, a separate d/usr/include, d/usr/lib, etc., not the real one for my system). I have shell script wrappers around GCC and its various tools that invoke it with the right paths to force this to happen, and when I call Python's configure I send along CC=sysroot-gcc, etc. for all the various tools. Note that it's not really a cross-compilation because the target is also a GNU/Linux system on the same hardware architecture. The majority of Python builds just fine like this. However, I'm having serious problems building modules such as fcntl, etc. Looking at the output from the makefile, I can see that somehow, someone is forcibly adding -I/usr/include/x86_64-linux-gnu to the link line: building 'termios' extension sysroot-gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I/usr/include/x86_64-linux-gnu -I/common/sysroot/tools/usr/include -I/common/sysroot/tools/usr/include-fixed -I/usr/local/include -I/home/workspaces/psmith/python/obj/src/Python-2.7.5/Include -I/home/workspaces/psmith/python/obj/bld/python -c /home/workspaces/psmith/python/obj/src/Python-2.7.5/Modules/termios.c -o build/temp.linux-x86_64-2.7/home/workspaces/psmith/python/obj/src/Python-2.7.5/Modules/termios.o This fails miserably because the headers in /usr/include/x86_64-linux-gnu do not play at all nicely with my other sysroot headers. Ditto for other extensions like fcntl, etc. I've searched high and low in the Python source, generated makefiles, config.log, etc. and I cannot find where this -I flag is coming from anywhere. I found the --oldincludedir flag to configure and set it to point into my sysroot as well, but that didn't help: the /usr/include still appears when building these extensions. Can anyone tell me where Python is getting these -I flags and what I need to do to tell it to NOT use those flags when building extensions? I'd also like to remove the -I/usr/local/include, although this is not actually causing me problems right now. ___ 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] Problem building Python 2.7.5 with separate sysroot
In article 1369986770.4119.43.camel@homebase, Paul Smith p...@mad-scientist.net wrote: Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14) system, but using a different sysroot (that is, a separate d/usr/include, d/usr/lib, etc., not the real one for my system). This list is for the development of Python itself, not about using or installing it. Python-list (AKA comp.lang.python) is the right list to ask such questions. That said ... However, I'm having serious problems building modules such as fcntl, etc. Looking at the output from the makefile, I can see that somehow, someone is forcibly adding -I/usr/include/x86_64-linux-gnu to the link line: [...] ... include file and library file selections for building standard library modules are handled by the top-level setup.py file in the source tree. That's where /usr/local/... is added and chances are that the above header is being added by add_gcc_paths() in setup.py. -- Ned Deily, n...@acm.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 443 - request for pronouncement
Hello python-dev, PEP 443 is ready for final review. I'm attaching the latest version below for convenience. The full history of changes is available here: http://hg.python.org/peps/log/tip/pep-0443.txt A reference implementation for PEP 443 is available at: http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363 with relevant tests here: http://hg.python.org/features/pep-443/file/tip/Lib/test/test_functools.py#l855 and documentation here: http://hg.python.org/features/pep-443/file/tip/Doc/library/functools.rst#l189 There's also an official backport for 2.6 - 3.3 already up: https://pypi.python.org/pypi/singledispatch PEP: 443 Title: Single-dispatch generic functions Version: $Revision$ Last-Modified: $Date$ Author: Łukasz Langa luk...@langa.pl Discussions-To: Python-Dev python-dev@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 22-May-2013 Post-History: 22-May-2013, 25-May-2013, 31-May-2013 Replaces: 245, 246, 3124 Abstract This PEP proposes a new mechanism in the ``functools`` standard library module that provides a simple form of generic programming known as single-dispatch generic functions. A **generic function** is composed of multiple functions implementing the same operation for different types. Which implementation should be used during a call is determined by the dispatch algorithm. When the implementation is chosen based on the type of a single argument, this is known as **single dispatch**. Rationale and Goals === Python has always provided a variety of built-in and standard-library generic functions, such as ``len()``, ``iter()``, ``pprint.pprint()``, ``copy.copy()``, and most of the functions in the ``operator`` module. However, it currently: 1. does not have a simple or straightforward way for developers to create new generic functions, 2. does not have a standard way for methods to be added to existing generic functions (i.e., some are added using registration functions, others require defining ``__special__`` methods, possibly by monkeypatching). In addition, it is currently a common anti-pattern for Python code to inspect the types of received arguments, in order to decide what to do with the objects. For example, code may wish to accept either an object of some type, or a sequence of objects of that type. Currently, the obvious way to do this is by type inspection, but this is brittle and closed to extension. Abstract Base Classes make it easier to discover present behaviour, but don't help adding new behaviour. A developer using an already-written library may be unable to change how their objects are treated by such code, especially if the objects they are using were created by a third party. Therefore, this PEP proposes a uniform API to address dynamic overloading using decorators. User API To define a generic function, decorate it with the ``@singledispatch`` decorator. Note that the dispatch happens on the type of the first argument, create your function accordingly:: from functools import singledispatch @singledispatch ... def fun(arg, verbose=False): ... if verbose: ... print(Let me just say,, end= ) ... print(arg) To add overloaded implementations to the function, use the ``register()`` attribute of the generic function. It is a decorator, taking a type parameter and decorating a function implementing the operation for that type:: @fun.register(int) ... def _(arg, verbose=False): ... if verbose: ... print(Strength in numbers, eh?, end= ) ... print(arg) ... @fun.register(list) ... def _(arg, verbose=False): ... if verbose: ... print(Enumerate this:) ... for i, elem in enumerate(arg): ... print(i, elem) To enable registering lambdas and pre-existing functions, the ``register()`` attribute can be used in a functional form:: def nothing(arg, verbose=False): ... print(Nothing.) ... fun.register(type(None), nothing) The ``register()`` attribute returns the undecorated function which enables decorator stacking, pickling, as well as creating unit tests for each variant independently:: @fun.register(float) ... @fun.register(Decimal) ... def fun_num(arg, verbose=False): ... if verbose: ... print(Half of your number:, end= ) ... print(arg / 2) ... fun_num is fun False When called, the generic function dispatches on the type of the first argument:: fun(Hello, world.) Hello, world. fun(test., verbose=True) Let me just say, test. fun(42, verbose=True) Strength in numbers, eh? 42 fun(['spam', 'spam', 'eggs', 'spam'], verbose=True) Enumerate this: 0 spam 1 spam 2 eggs 3 spam fun(None) Nothing. fun(1.23) 0.615 Where there is no registered implementation for a specific type, its method resolution order is used to find a more generic implementation. To check which implementation will the generic
Re: [Python-Dev] PEP 443 - request for pronouncement
On 31 maj 2013, at 12:18, Gustavo Carneiro gjcarne...@gmail.com wrote: It is not clear from the PEP (up until the end of the User API section at least) when, if ever, is this implementation of fun ever called. I mean, what type of 'arg' triggers a dispatch to this function body? I added a sentence clarifying that. See the commit: http://hg.python.org/peps/rev/4d6c827944c4 Does that address your concern? So my comment is just about clarity of the PEP text. I do not wish to interfere with pronouncement. Sure thing. Thanks for your feedback! -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ 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 443 - request for pronouncement
On Fri, May 31, 2013 at 11:34 AM, Łukasz Langa luk...@langa.pl wrote: On 31 maj 2013, at 12:18, Gustavo Carneiro gjcarne...@gmail.com wrote: It is not clear from the PEP (up until the end of the User API section at least) when, if ever, is this implementation of fun ever called. I mean, what type of 'arg' triggers a dispatch to this function body? I added a sentence clarifying that. See the commit: http://hg.python.org/peps/rev/4d6c827944c4 Does that address your concern? Yes, much better now. Thank you! ___ 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] Problem building Python 2.7.5 with separate sysroot
On Fri, 2013-05-31 at 01:21 -0700, Ned Deily wrote: In article 1369986770.4119.43.camel@homebase, Paul Smith p...@mad-scientist.net wrote: Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14) system, but using a different sysroot (that is, a separate d/usr/include, d/usr/lib, etc., not the real one for my system). This list is for the development of Python itself, not about using or installing it. Python-list (AKA comp.lang.python) is the right list to ask such questions. That said ... However, I'm having serious problems building modules such as fcntl, etc. Looking at the output from the makefile, I can see that somehow, someone is forcibly adding -I/usr/include/x86_64-linux-gnu to the link line: [...] ... include file and library file selections for building standard library modules are handled by the top-level setup.py file in the source tree. That's where /usr/local/... is added and chances are that the above header is being added by add_gcc_paths() in setup.py. Yes, thank you. It seems to me (keeping with the theme of this mailing list) that the add_multiarch_paths() function in setup.py is not right. The first step, which asks the compiler about multi-arch, is OK because it's using my alternate compiler which reports no multiarch. But then it proceeds to run the local host version of dpkg-architecture. I see that it adds the -t flag if cross-compiling, which I'm not, but even that is not fixing the issue. If you're building on a system which is Debian derived with multi-arch support you will ALWAYS have your local /usr/include (plus some multiarch suffix) -- and '/usr/lib' + multiarch -- added to your include and lib paths; this is not good. My case may be unusual but even in a more formal cross-compilation environment it's not good to add /usr/include/..., or base such a decision on the behavior of the _build_ system. ___ 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 443 - request for pronouncement
Sorry, maybe I am too late to comment on this, but,
@singledispatch
... def fun(arg, verbose=False):
... if verbose:
... print(Let me just say,, end= )
... print(arg)
It is not clear from the PEP (up until the end of the User API section at
least) when, if ever, is this implementation of fun ever called. I mean,
what type of 'arg' triggers a dispatch to this function body?
I am guessing that when the arg does not match the type of any of the other
registered functions, this function body is used by default. But it is
only a guess, the PEP doesn't state this clearly.
If my guess is true, would it be reasonable to update the example def fun
code to reflect this, e.g., to print(Warning: I do not know what to do
with arg {} of type {}.format(arg, type(arg)).
So my comment is just about clarity of the PEP text. I do not wish to
interfere with pronouncement.
Thanks.
On Fri, May 31, 2013 at 10:46 AM, Łukasz Langa luk...@langa.pl wrote:
Hello python-dev,
PEP 443 is ready for final review. I'm attaching the latest
version below for convenience. The full history of changes
is available here: http://hg.python.org/peps/log/tip/pep-0443.txt
A reference implementation for PEP 443 is available at:
http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363
with relevant tests here:
http://hg.python.org/features/pep-443/file/tip/Lib/test/test_functools.py#l855
and documentation here:
http://hg.python.org/features/pep-443/file/tip/Doc/library/functools.rst#l189
There's also an official backport for 2.6 - 3.3 already up:
https://pypi.python.org/pypi/singledispatch
PEP: 443
Title: Single-dispatch generic functions
Version: $Revision$
Last-Modified: $Date$
Author: Łukasz Langa luk...@langa.pl
Discussions-To: Python-Dev python-dev@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 22-May-2013
Post-History: 22-May-2013, 25-May-2013, 31-May-2013
Replaces: 245, 246, 3124
Abstract
This PEP proposes a new mechanism in the ``functools`` standard library
module that provides a simple form of generic programming known as
single-dispatch generic functions.
A **generic function** is composed of multiple functions implementing
the same operation for different types. Which implementation should be
used during a call is determined by the dispatch algorithm. When the
implementation is chosen based on the type of a single argument, this is
known as **single dispatch**.
Rationale and Goals
===
Python has always provided a variety of built-in and standard-library
generic functions, such as ``len()``, ``iter()``, ``pprint.pprint()``,
``copy.copy()``, and most of the functions in the ``operator`` module.
However, it currently:
1. does not have a simple or straightforward way for developers to
create new generic functions,
2. does not have a standard way for methods to be added to existing
generic functions (i.e., some are added using registration
functions, others require defining ``__special__`` methods, possibly
by monkeypatching).
In addition, it is currently a common anti-pattern for Python code to
inspect the types of received arguments, in order to decide what to do
with the objects. For example, code may wish to accept either an object
of some type, or a sequence of objects of that type.
Currently, the obvious way to do this is by type inspection, but this
is brittle and closed to extension. Abstract Base Classes make it easier
to discover present behaviour, but don't help adding new behaviour.
A developer using an already-written library may be unable to change how
their objects are treated by such code, especially if the objects they
are using were created by a third party.
Therefore, this PEP proposes a uniform API to address dynamic
overloading using decorators.
User API
To define a generic function, decorate it with the ``@singledispatch``
decorator. Note that the dispatch happens on the type of the first
argument, create your function accordingly::
from functools import singledispatch
@singledispatch
... def fun(arg, verbose=False):
... if verbose:
... print(Let me just say,, end= )
... print(arg)
To add overloaded implementations to the function, use the
``register()`` attribute of the generic function. It is a decorator,
taking a type parameter and decorating a function implementing the
operation for that type::
@fun.register(int)
... def _(arg, verbose=False):
... if verbose:
... print(Strength in numbers, eh?, end= )
... print(arg)
...
@fun.register(list)
... def _(arg, verbose=False):
... if verbose:
... print(Enumerate this:)
... for i, elem in enumerate(arg):
... print(i, elem)
To enable registering lambdas and pre-existing functions, the
``register()`` attribute can be used in a functional
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-05-24 - 2013-05-31) 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: open3997 (+25) closed 25884 (+34) total 29881 (+59) Open issues with patches: 1780 Issues opened (45) == #6386: importing yields unexpected results when initial script is a s http://bugs.python.org/issue6386 reopened by ncoghlan #17269: getaddrinfo segfaults on OS X when provided with invalid argum http://bugs.python.org/issue17269 reopened by ned.deily #18050: embedded interpreter or virtualenv fails with ImportError: ca http://bugs.python.org/issue18050 opened by samueljohn #18052: IDLE 3.3.2 Windows taskbar icon regression http://bugs.python.org/issue18052 opened by terry.reedy #18053: Add checks for Misc/NEWS in make patchcheck http://bugs.python.org/issue18053 opened by Yogesh.Chaudhari #18054: Add more exception related assertions to unittest http://bugs.python.org/issue18054 opened by ncoghlan #18055: Stop using imp in IDLE http://bugs.python.org/issue18055 opened by brett.cannon #18056: Document importlib._bootstrap.NamespaceLoader http://bugs.python.org/issue18056 opened by brett.cannon #18057: Register NamespaceLoader with importlib.abc.Loader http://bugs.python.org/issue18057 opened by brett.cannon #18058: Define is_package for NamespaceLoader http://bugs.python.org/issue18058 opened by brett.cannon #18059: Add multibyte encoding support to pyexpat http://bugs.python.org/issue18059 opened by serhiy.storchaka #18060: Updating _fields_ of a derived struct type yields a bad cif http://bugs.python.org/issue18060 opened by lauri.alanko #18061: m68k Python 3.3 test results http://bugs.python.org/issue18061 opened by mirabilos #18062: m68k FPU precision issue http://bugs.python.org/issue18062 opened by mirabilos #18064: IDLE: add current directory to open_module http://bugs.python.org/issue18064 opened by terry.reedy #18065: set __path__ = [] for frozen packages http://bugs.python.org/issue18065 opened by brett.cannon #18066: Remove SGI-specific code from pty.py http://bugs.python.org/issue18066 opened by akuchling #18068: pickle + weakref.proxy(self) http://bugs.python.org/issue18068 opened by phd #18069: Subprocess picks the wrong executable on Windows http://bugs.python.org/issue18069 opened by berdario #18071: _osx_support compiler_fixup http://bugs.python.org/issue18071 opened by samueljohn #18073: pickle.Unpickler may read too many bytes, causing hangs with b http://bugs.python.org/issue18073 opened by jm #18076: Implement importlib.util.decode_source_bytes() http://bugs.python.org/issue18076 opened by brett.cannon #18078: threading.Condition to allow notify on a specific waiter http://bugs.python.org/issue18078 opened by JBernardo #18081: test_logging failure in WarningsTest on buildbots http://bugs.python.org/issue18081 opened by r.david.murray #18082: Inconsistent behavior of IOBase methods on closed files http://bugs.python.org/issue18082 opened by dwight.guth #18083: _sysconfigdata.py is installed in an arch-independent director http://bugs.python.org/issue18083 opened by automatthias #18085: Verifying refcounts.dat http://bugs.python.org/issue18085 opened by serhiy.storchaka #18088: Create importlib.abc.Loader.init_module_attrs() http://bugs.python.org/issue18088 opened by brett.cannon #18089: Create importlib.abc.InspectLoader.load_module() http://bugs.python.org/issue18089 opened by brett.cannon #18090: dict_contains first argument declared register, and shouldn't http://bugs.python.org/issue18090 opened by larry #18091: Remove PyNoArgsFunction http://bugs.python.org/issue18091 opened by larry #18092: Python 2.7.5 installation broken on OpenSuse 12.2 http://bugs.python.org/issue18092 opened by Andreas.Jung #18093: Move main functions to a separate Programs directory http://bugs.python.org/issue18093 opened by ncoghlan #18094: Skip tests in test_uuid not silently http://bugs.python.org/issue18094 opened by serhiy.storchaka #18095: unable to invoke socket.connect with AF_UNSPEC http://bugs.python.org/issue18095 opened by Roman.Valov #18096: bad library order returned by python-config.in http://bugs.python.org/issue18096 opened by taylor #18099: wsgiref sets Content-Length: 0 on 304 Not Modified http://bugs.python.org/issue18099 opened by flox #18100: socket.sendall() cannot send buffers of 2GB or more http://bugs.python.org/issue18100 opened by Tom.van.Leeuwen #18101: Tk.split() doesn't work with nested Unicode strings http://bugs.python.org/issue18101 opened by serhiy.storchaka #18102: except-clause with own exception class inside generator can le http://bugs.python.org/issue18102 opened by hagen #18103: Create a GUI test framework for Idle http://bugs.python.org/issue18103 opened by terry.reedy #18104: Idle: make human-mediated GUI tests usable
Re: [Python-Dev] Problem building Python 2.7.5 with separate sysroot
In article 137129.4119.53.camel@homebase, Paul Smith p...@mad-scientist.net wrote: It seems to me (keeping with the theme of this mailing list) that the add_multiarch_paths() function in setup.py is not right. [...] If you think there is a problem, please open an issue for it on the Python bug tracker: http://bugs.python.org. Thanks! -- Ned Deily, n...@acm.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] [Python-checkins] cpython: Add a reset_name argument to importlib.util.module_to_load in order to
I realize this broke the buildbots. Missed part of a diff in the commit.
I'm trying to split a massive CL into reasonable commit sizes, so please be
patient.
On Fri, May 31, 2013 at 6:11 PM, brett.cannon python-check...@python.orgwrote:
http://hg.python.org/cpython/rev/39cc1b04713e
changeset: 83998:39cc1b04713e
user:Brett Cannon br...@python.org
date:Fri May 31 18:11:17 2013 -0400
summary:
Add a reset_name argument to importlib.util.module_to_load in order to
control whether to reset the module's __name__ attribute in case a
reload is being done.
files:
Doc/library/importlib.rst| 6 +-
Lib/importlib/_bootstrap.py | 14 +-
Lib/test/test_importlib/test_util.py | 12
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst
--- a/Doc/library/importlib.rst
+++ b/Doc/library/importlib.rst
@@ -788,7 +788,7 @@
.. versionadded:: 3.3
-.. function:: module_to_load(name)
+.. function:: module_to_load(name, *, reset_name=True)
Returns a :term:`context manager` which provides the module to load.
The
module will either come from :attr:`sys.modules` in the case of
reloading or
@@ -796,6 +796,10 @@
:attr:`sys.modules` occurs if the module was new and an exception was
raised.
+If **reset_name** is true and the module requested is being reloaded
then
+the module's :attr:`__name__` attribute will
+be reset to **name**, else it will be left untouched.
+
.. versionadded:: 3.4
.. decorator:: module_for_loader
diff --git a/Lib/importlib/_bootstrap.py b/Lib/importlib/_bootstrap.py
--- a/Lib/importlib/_bootstrap.py
+++ b/Lib/importlib/_bootstrap.py
@@ -493,8 +493,14 @@
-def __init__(self, name):
+def __init__(self, name, *, reset_name=True):
+Prepare the context manager.
+
+The reset_name argument specifies whether to unconditionally reset
+the __name__ attribute if the module is found to be a reload.
+
self._name = name
+self._reset_name = reset_name
def __enter__(self):
self._module = sys.modules.get(self._name)
@@ -508,6 +514,12 @@
# (otherwise an optimization shortcut in import.c becomes
wrong)
self._module.__initializing__ = True
sys.modules[self._name] = self._module
+elif self._reset_name:
+try:
+self._module.__name__ = self._name
+except AttributeError:
+pass
+
return self._module
def __exit__(self, *args):
diff --git a/Lib/test/test_importlib/test_util.py
b/Lib/test/test_importlib/test_util.py
--- a/Lib/test/test_importlib/test_util.py
+++ b/Lib/test/test_importlib/test_util.py
@@ -55,6 +55,18 @@
else:
self.fail('importlib.util.module_to_load swallowed an
exception')
+def test_reset_name(self):
+# If reset_name is true then module.__name__ = name, else leave
it be.
+odd_name = 'not your typical name'
+created_module = imp.new_module(self.module_name)
+created_module.__name__ = odd_name
+sys.modules[self.module_name] = created_module
+with util.module_to_load(self.module_name) as module:
+self.assertEqual(module.__name__, self.module_name)
+created_module.__name__ = odd_name
+with util.module_to_load(self.module_name, reset_name=False) as
module:
+self.assertEqual(module.__name__, odd_name)
+
class ModuleForLoaderTests(unittest.TestCase):
--
Repository URL: http://hg.python.org/cpython
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins
___
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
