On Tue, 28 May 2013 23:29:46 +0200 (CEST)
brett.cannon <python-checkins(a)python.org> wrote:
> +.. class:: ModuleManager(name)
> + 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 a fresh
> + module if loading a new module. Proper cleanup of :attr:`sys.modules` occurs
> + if the module was new and an exception was raised.
What use case does this API solve?
(FWIW, I think "ModuleManager" is a rather bad name :-))
Here's something that seems to come up from time to time in Debian.
Take a Python application like tox, nose, or pyflakes. Their executables work
with both Python 2 and 3, but require a #! line to choose which interpreter to
When we add Python 3 support in Debian for such a script, all the library
installations are handled just fine, but we have conflicts about what to name
the thing that lands in /usr/bin. Do we have /usr/bin/pyflakes and
/usr/bin/pyflakes3? Do we call the latter py3flakes (as has been convention
with some other scripts, but which breaks locate(1))? Do we simply remove the
/usr/bin scripts and encourage people to use something like `$python -m nose`?
One interesting recent suggestion is to create a shell driver script and make
that thing accept --py3 and --py2 flags, which would then select the
appropriate interpreter and invoke the actual Python driver. There are some
technical details to iron out with that, but there's some appeal to it.
Have any other *nix distros addressed this, and if so, how do you solve it?
It would be nice if we could have some cross-platform recommendations so
things work the same wherever you go. To that end, if we can reach some
consensus, I'd be willing to put together an informational PEP and some
scripts that might be of general use.
I have a feature branch where I'm intermittently working on the
bootstrapping changes described in PEP 432.
As part of those changes, I've cleaned up a few aspects of the repo layout:
* moved the main executable source file from Modules to a separate
* moved the _freezeimportlib and _testembed source files from Modules
to a separate Tools directory
* split the monster pythonrun.h/c pair into 3 separate header/impl pairs:
These structural changes generally mean automatic merges touching the
build machinery or the startup or shutdown code fail fairly
spectacularly and need a lot of TLC to complete them without losing
any changes from the main repo.
Would anyone object if I went ahead and posted patches for making
these changes to the main repo? I found they made the code *much*
easier to follow when I started to turn the ideas in PEP 432 into
working software, and implementing these shifts should make future
merges to my feature branch simpler, as well as producing
significantly cleaner diffs when PEP 432 gets closer to completion.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On Tue, 28 May 2013 15:06:39 -0400
Terry Reedy <tjreedy(a)udel.edu> wrote:
> On 5/28/2013 2:14 AM, Benjamin Peterson wrote:
> > 2013/5/27 terry.reedy <python-checkins(a)python.org>:
> >> http://hg.python.org/cpython/rev/c5d4c041ab47
> >> changeset: 83942:c5d4c041ab47
> >> parent: 83940:2ea849fde22b
> >> parent: 83941:24c3e7e08168
> >> user: Terry Jan Reedy <tjreedy(a)udel.edu>
> >> date: Mon May 27 21:33:40 2013 -0400
> >> summary:
> >> Merge with 3.3
> >> files:
> >> Lib/idlelib/CallTips.py | 4 +-
> >> Lib/idlelib/PathBrowser.py | 3 +-
> >> Lib/idlelib/idle_test/(a)README.txt | 63 +++++++++++
> > Is @README really the intended name of this file?
> Yes, Nick suggested README instead of what I had. I want a prefix to
> keep it near the top of a directory listing even when other non
> 'test_xxx' files are added. I thing '_' wold be better though.
I don't think "prefixing with a weird character so that the filename
show up top" is a very elegant trick, and we don't use it for other
directories. "README.txt" *will* be easily visible because of the
> If I can
> find how to rename in hg
"Rename in hg" -> "hg rename"
Pep 422 proposes the following order for dealing with cyclic isolates:
1. Weakrefs to CI objects are cleared, and their callbacks called. At
this point, the objects are still safe to use.
2. The finalizers of all CI objects are called.
3. The CI is traversed again to determine if it is still isolated. If
it is determined that at least one object in CI is now reachable from
outside the CI, this collection is aborted and the whole CI is
resurrected. Otherwise, proceed.
4. The CI becomes a CT as the GC systematically breaks all known
references inside it (using the tp_clear function).
Why are weakrefs are broken first, before determining if any of the
objects should become resurrected? Naively I would expect weakrefs to be
broken after step 3, once the system is sure no objects have been
I request that this information be added to PEP 422.
"There should be one-- and preferably only one --obvious way to do it."
We all love this mantra.
But one thing that often confuses people : function naming. The standard
library is kind of inconsistent. Some functions are separated by
underscores and others aren't. It's not intuitive and new pythonistas end
up constantly reading the doc. (Time saving one char typing vs time
guessing function names.)
Would it be a good idea to clarify PEP 8 on this ? I mean for future
In http://bugs.python.org/issue17936, I proposed making tp_subclasses
(the internal container implementing object.__subclasses__) a dict.
This would make the return order of __subclasses__ completely
undefined, while it is right now slightly predictable. I have never seen
__subclasses__ actually used in production code, so I'm wondering
whether someone might be affected by such a change.
On 24 maj 2013, at 14:53, Ronan Lamy <ronan.lamy(a)gmail.com> wrote:
>> 2013/5/24 Łukasz Langa <lukasz(a)langa.pl>
>> I recognize the need for such behaviour to be discoverable. This is
>> important for debugging purposes. This is why I'm going to let users
>> inspect registered overloads, as well as provide their own mapping
>> for the registry. I'm working on the reference implementation now,
>> stay tuned.
> OK, I agree that preventing silent overwriting is actually not desirable. Specifying an interface for the implementation registry sounds like the best possible solution to my concerns.
Users can now inspect the dispatcher and specify their own mapping for
ABC support is still not there, I'm working on it.
IRC: ambv on #python-dev