I'm sending this mail to Python-dev in the hope to reach more developers.
GvR likes to rename the __builtin__ to reduce confusing between
__builtin__ and __builtins__. He wanted to start a poll on the new name
but apparently he forgot.
In http://bugs.python.org/issue1774369 I mentioned that I wanted to
rename __builtins__ to __rootns__. Though right now I think something
longer and less cryptic might be better. The reason is to avoid for
once and for all the confusion between __builtin__, which is a module,
and __builtins__, a feature mainly used by sandboxing to pass the set of
builtins to be used via the global namespace. This lay at the heart of
the referenced bug.
I'm still in favor of this but haven't had the time to investigate how
much work it would be.
OK, then we need to agree on a new name. I find __root__ too short,
__rootns__ too cryptic, and __root_namespace__ too long. :-) What else
have we got?
What name do you prefer? I'm +1 with Raymond on __root__ but I'm still
open for better suggestions.
Two news. A big speed up, and now we reached some stable state.
Mark Dickinson found out that a lot of time was lost internally in
decimal.py when dealing with the Decimal mantissas.
He changed the way that mantissa was stored, from a tuple of ints, to
a plain string (each character a digit). This achieved a speedup of
around a 40%!!!
- The speedup was measured using two tools I created [*], one
basically tries a lot of use cases, the other use the specification
test cases. Both generate a .py which actually measures the times.
- No API was changed, and this a good thing, :)
- The change is somewhat big. But as the speedup is important, and the
API es untouched, I considered it was something that worths it.
After several months with a lot of work here, no more big changes are
planned to this module, so I will backport it to 2.5.3 (when the trunk
gets unfrozen). Note that the module complies with the latest
specification and with the latest test cases (that are from one month
Thanks Mark for all your effort here!
I've updated PEP 366 with a proposed implementation, as well as a few
changes to the proposed semantics to make the implementation feasible
(the old proposal called for imp.new_module to calculate a value when it
didn't have access to all of the relevant information).
The updated text is below, and should turn up on python.org before too long.
Title: Main module explicit relative imports
Author: Nick Coghlan <ncoghlan(a)gmail.com>
Type: Standards Track
Python-Version: 2.6, 3.0
Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007, 23-Nov-2007
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.
By adding a new module level attribute, this PEP allows relative imports
to work automatically if the module is executed using the ``-m`` switch.
A small amount of boilerplate in the module itself will allow the relative
imports to work when the file is executed by name.
The major proposed change is the introduction of a new module level
attribute, ``__package__``. When it is present, relative imports will
be based on this attribute rather than the module ``__name__``
As with the current ``__name__`` attribute, setting ``__package__`` will
be the responsibility of the PEP 302 loader used to import a module.
Loaders which use ``imp.new_module()`` to create the module object will
have the new attribute set automatically to ``None``. When the import
system encounters an explicit relative import in a module without
``__package__`` set (or with it set to ``None``), it will calculate and
store the correct value (``__name__.rpartition('.')`` for normal
modules and ``__name__`` for package initialisation modules). If
``__package__`` has already been set then the import system will use
it in preference to recalculating the package name from the
``__name__`` and ``__path__`` attributes.
The ``runpy`` module will explicitly set the new attribute, basing it off
the name used to locate the module to be executed rather than the name
used to set the module's ``__name__`` attribute. This will allow relative
imports to work correctly from main modules executed with the ``-m``
When the main module is specified by its filename, then the
``__package__`` attribute will be set to ``None``. To allow
relative imports when the module is executed directly, boilerplate
similar to the following would be needed before the first relative
if __name__ == "__main__" and __package__ is None:
__package__ = "expected.package.name"
Note that this boilerplate is sufficient only if the top level package
is already accessible via ``sys.path``. Additional code that manipulates
``sys.path`` would be needed in order for direct execution to work
without the top level package already being importable.
This approach also has the same disadvantage as the use of absolute
imports of sibling modules - if the script is moved to a different
package or subpackage, the boilerplate will need to be updated
manually. It has the advantage that this change need only be made
once per file, regardless of the number of relative imports.
Rationale for Change
The current inability to use explicit relative imports from the main
module is the subject of at least one open SF bug report (#1510172) _,
and has most likely been a factor in at least a few queries on
comp.lang.python (such as Alan Isaac's question in _).
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.
The section in PEP 338 on relative imports and the main module provides
further details and background on this problem.
Rev 47142 in SVN implemented an early variant of this proposal
which stored the main module's real module name in the
``__module_name__`` attribute. It was reverted due to the fact
that 2.5 was already in beta by that time.
Patch 1487  is the proposed implementation for this PEP.
PEP 3122 proposed addressing this problem by changing the way
the main module is identified. That's a significant compatibility cost
to incur to fix something that is a pretty minor bug in the overall
scheme of things, and the PEP was rejected _.
The advantage of the proposal in this PEP is that its only impact on
normal code is the small amount of time needed to set the extra
attribute when importing a module. Relative imports themselves should
be sped up fractionally, as the package name is cached in the module
globals, rather than having to be worked out again for each relative
..  Absolute/relative import not working?
..  c.l.p. question about modules and relative imports
..  Guido's rejection of PEP 3122
..  PEP 366 implementation patch
This document has been placed in the public domain.
On both of my systems, using -O2 reduces execution time in pystone by 9%
and in pybench by 8%. It's function inlining: "-O3
-fno-inline-functions" works just as well as "-O2". Removing "-g" has
little effect on the result.
- AMD Athlon 64 X2 Dual Core 4600+, 512 KB cache (desktop)
- Intel T2300 Dual Core 1.66GHz, 512 KB cache (laptop)
Both are Ubuntu 7.04, GCC 4.1.2.
Does anybody else see this?
It may be GCC being stupid (which has happened before) or not enough
cache on my systems (definitely possible). If it's not one of those, I'd
say it's because CPython core functions are already very large, and
almost everything that ought to be inlined is already a macro.
Pybench comparison for the Athlon:
Sorry if this is a dumb question, but are there actually good reasons to remove "types"?
IMHO the types module helps keeping code readable.
"if type(obj) == FloatType"
is just more readable than
"if type(obj) == type(1.0)".
Luckily Python does not distinguish float and double like other languages
- otherwise it wouldn't be clear for the average programmer if 1.0 is a
float or a double constant.
since ssl module is still in development I thought it would have been
better asking such question here instead of on comp.lang.python.
I'm interested in using the ssl module with asyncore but since there's
no real documentation about it yet I've been not able to write
something useful with it.
Currently I'm trying to add the SSL support to an asyncore-based FTP
server I wrote.
I tried to write some code by watching the ssl-related test-suite
scripts with no luck since there are no available tests for asyncore
I tried to play with the wrap_socket() function a little bit but
different type of errors are raised every time.
I'm sure this happens because I'm not doing things in the right way.
Could someone please show me an example code about how the ssl module
could be integrated with asyncore?
I was looking at statsvn today at work and gave it a test-run on a repo there.
I wondered what it would look like for python3k. And... here are the results: