New submission from Nick Coghlan :
$ ./python -Wdefault
Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06)
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>&
Nick Coghlan added the comment:
The problem turned out to just be inspect.getmodulename() still relying on the
deprecated inspect.getmoduleinfo(), so I changed it to be based on
importlib.machinery instead.
I did make an importlib API addition to do it though - the all_suffixes()
function
Nick Coghlan added the comment:
Yup. A simpler demonstration:
Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06)
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>
Nick Coghlan added the comment:
Checking with importlib.abc and importlib.util (which turned out not to have
the problem) put me on the right path: the problem is the import of "imp" in
importlib.__init__
What appears to be happening is that the interpreter sees the partially
i
Nick Coghlan added the comment:
Agreed, so definite +1 from me.
--
___
Python tracker
<http://bugs.python.org/issue15368>
___
___
Python-bugs-list mailin
New submission from Nick Coghlan :
s/dics/dicts/
http://hg.python.org/cpython/file/default/Lib/inspect.py#l1049
--
assignee: ncoghlan
messages: 165893
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Typo in inspect.getclosurevars docstring
Nick Coghlan added the comment:
Ah, that makes sense - since the zip file doesn't exist on buildbots, returning
None is the correct result.
Mystery explained, thanks :)
--
resolution: -> invalid
status: open -> closed
title: pkgutil.get_importer("") was retu
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue15386>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
No worries - I only did that as a reminder to fix it when I got home tonight.
It's bugs like this where I wish we had the infrastructure for Github-style
online code editing set up :)
--
___
Python tracker
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15091>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue15091>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan added the comment:
Oh, wow, that was a *lot* harder than I expected to create a test for - I had
to import importlib right at the start of regrtest, as well as tweak the import
order in runpy, and doing so actually caused test_import to *crash* completely
without the bug fixed
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg165921
___
Python tracker
<http://bugs.python.org/issue15091>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
That was a *lot* harder than I expected to create a test for - I had to import
importlib right at the start of regrtest, as well as tweak the import order in
runpy, and doing so actually caused test_import to *crash* completely without
the bug fixed.
The
Changes by Nick Coghlan :
--
nosy: +larry, ncoghlan
___
Python tracker
<http://bugs.python.org/issue15295>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
>From the import-sig discussions, this wasn't just about documenting PEP 420,
>it was about finally bringing the full import system specification into the
>language reference. (Now that it doesn't need to be loaded with caveats about
>
Nick Coghlan added the comment:
Yup. It's unfortunate, but there's really nothing we can do about it - some
protocols use exceptions, and if you raise an exception type that is part of
the defined protocol as the result of a genuine error, then you're going to
have a fun deb
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue10399>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nick Coghlan :
The current implementation of PEP 391 relies on eval, which is substantially
more permissive than the expected syntax described in the spec. This means the
listen() feature provides an attack vector for injection of untrusted code.
While the documentation
Nick Coghlan added the comment:
The precedence problems described in #11477 shouldn't factor into this case -
that issue is specific to C level types that implement + and * via
tp_as_sequence *without* implementing the corresponding slots in tp_as_number.
That's not the case h
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue15403>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15415>
___
___
Python-bugs-list mai
Nick Coghlan added the comment:
This is a tricky one. Long term, the right approach is to migrate all the
"scripts that run other scripts" over to runpy, but the runpy API needs work
before we can do that (see #9325).
For bug fix purposes though, these modules can borrow some
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15355>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nick Coghlan :
As far as I can tell, the only mentions of the C API version macros are:
1. In the prose for the stable ABI section (incidentally: this section has a
typo in the title)
2. In the documentation for sys.hexversion
There should be a clear "API an
Changes by Nick Coghlan :
--
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue15465>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
Georg, need a call on how close you are to cutting beta 2 and whether you want
this to wait until rc1.
--
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker
___
Python tracker
&l
Nick Coghlan added the comment:
Summary of my review for Georg's benefit: I had one minor formatting nit with
the patch (which Stefan can easily fix before committing), but it otherwise
looked fine to me.
I also agree that the old implicit truncation was unusable in practice, as the
*a
Nick Coghlan added the comment:
Everything is still building happily for me on Fedora, so I suggest looking at
the Debian/Ubuntu multiarch support (which is the origin of the
dpkg-architecture call).
Background in http://bugs.python.org/issue11715
--
nosy: +barry, ncoghlan
Nick Coghlan added the comment:
The specific bug is that, in 3.2, the claimed default (level=0) is not
accurate: the default is actually (level=-1), as it was in 2.x. The import
statement passes level=0 explicitly (as it does in 2.x when "from __future__
import absolute_import" is
Nick Coghlan added the comment:
s/not added/note added/
--
___
Python tracker
<http://bugs.python.org/issue15482>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
Was the point that memoryview.tobytes() has a known data corruption bug in 3.2
and 2.7 raised in the previous discussion? I'm pretty sure I had forgotten
about it, and I don't remember it coming up in the thread.
The trickiest aspect of a backport
Nick Coghlan added the comment:
See the porting notes:
http://docs.python.org/dev/whatsnew/3.3.html#porting-python-code
With the removal of the implicit default finder, the 3.3 semantics are that
both None *and* imp.NullImporter mean "There is no importer for this
Nick Coghlan added the comment:
I know ast.literal_eval() isn't enough - that's why I suggested the addition of
ast.lookup_eval() in the opening post.
As far as your other suggestion goes, don't reinvent crypto badly - if you want
to provide authentication support in listen
Changes by Nick Coghlan :
--
hgrepos: +142
___
Python tracker
<http://bugs.python.org/issue15295>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I would title the new section "Import system" rather than "Import machinery" as
it is meant to be a specification documentation rather than an implementation
description.
Import statement:
The statement that "from X import A"
Nick Coghlan added the comment:
General comment:
runpy, pkgutil, et al should all get "See Also" links at the top pointing to
the new import system section.
Import system intro:
As noted above, I suggest changing the name :)
Opening section should refer to importlib.import_mod
Nick Coghlan added the comment:
Great start here Barry, I'll switch my checkout over to read/write access and
start contributing fixes.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
Pushed the import machinery -> import system change (which hopefully won't
break Barry's world)
Also merged in a more recent version of trunk. This probably screwed up the
default branch in this clone, but the clone should be done after these
Nick Coghlan added the comment:
I've switched back to being -1 on the PYTHONRUNFIRST idea. There are no ACLs
for environment variables, so the security implications scare me too much for
me to support the feature.
The simple -C option doesn't have that problem, though, and could
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15425>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Added patch with test cases for the situations Amaury picked up, as well
another I noticed (when the from clause refers to a module that fails)
--
Added file: http://bugs.python.org/file26564/issue15425_test_cases.diff
Nick Coghlan added the comment:
I actually did start refactoring a lot of this when I was working on the
pkgutil changes, but stopped because that patch was already hairy enough.
Maybe I should have kept going...
--
___
Python tracker
<h
Nick Coghlan added the comment:
I think tuning the "what frames to hide" heuristic is a better bet - I remember
know that the real reason I stopped messing with which exceptions were thrown
was that I ended up confusing pkgutil.
--
Nick Coghlan added the comment:
Fixed test case patch - previous one included a comment from when my test was
buggy.
--
Added file: http://bugs.python.org/file26565/issue15425_test_cases.diff
___
Python tracker
<http://bugs.python.org/issue15
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file26564/issue15425_test_cases.diff
___
Python tracker
<http://bugs.python.org/issue15425>
___
___
Pytho
Nick Coghlan added the comment:
OK, to investigate the failures a bit further, I turned off the traceback
suppression altogether by sticking an immediate return at the start of
remove_importlib_frames. For the three failing tests, this is what I got when
adding a traceback.print_tb call
Nick Coghlan added the comment:
I realised that it is my test that was wrong in the syntax error case. Attached
patch includes the test cases, and the fix for that case.
The weird thing that still requires an explanation is why the chunks in the
first two cases are only being partially
Nick Coghlan added the comment:
Ah, it turns out the three problem children are those which accept an "import_"
callback, which is set to builtins.__import__ when accessed via the import
statement. This means we end up making a *recursive* call to
PyImport_ImportModuleLevelObject, w
Changes by Nick Coghlan :
--
title: memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for
non-contiguous arrays -> memoryview.to_bytes() and PyBuffer_ToContiguous()
incorrect for non-contiguous arrays
___
Python tracker
&l
Nick Coghlan added the comment:
I'll at least introduce a "_recursive_import" exit point to simplify handling
of those three cases. For those, if there isn't another importlib frame on the
stack below them, odds are pretty good that it has b
Nick Coghlan added the comment:
I think the implementation I just checked in is close to being as simple as we
can get:
Blocks ending in _exec_module and _recursive_import are trimmed unconditionally
For SyntaxError, it also trims blocks ending in get_code
For ImportError, it trims everything
Nick Coghlan added the comment:
On second thought, I realised having a general purpose "hide this" hook means
that any future unconditional cases can easily be hidden just by changing from
the normal call to a stripped call. I'll imp
New submission from Nick Coghlan:
Thanks to issue #15425, the number of special cases in the importlib frame
stripping is growing. This patch tweaks the frame stripping mechanism to make
it easy to selectively strip frames in importlib._bootstrap by creating a
_call_with_frames_removed helper
Nick Coghlan added the comment:
Seeing as the blocker is dealt with for beta2, see #15486 for the proposed
refactoring.
--
___
Python tracker
<http://bugs.python.org/issue15
Nick Coghlan added the comment:
In trying to find a new case that wasn't already covered by the test suite, I
found an error which I'm not even sure should be an error. Doesn't 3.2 suppress
failures that occur when attempting to implicitly cache the .pyc?
Anyway, given the re
Nick Coghlan added the comment:
Updated the statement docs to accurately describe the from X import Y case.
I also noted that unlike the statement form, importlib.import_module ignores
module level __import__ overrides.
--
___
Python tracker
<h
Nick Coghlan added the comment:
Nothing too complicated - just noting that a test suite like ours that launches
Python subprocesses to test process global state handling could fairly easily
arrange to pass appropriate -C options to trigger things like recording
coverage data or profiling
Nick Coghlan added the comment:
I suspect the need to preserve the C ABI would make a complete backport a
challenge. I'm still tempted though, mainly to give third parties a robust core
implementation of the buffer API to test against.
This is especially so with Python 2.7 still hav
Nick Coghlan added the comment:
There are two different use cases here. "-C" tackles one of them,
"PYTHONRUNFIRST" the other.
My original use case came from working on the Python test suite. In that suite,
we have "test.script_helper" which spawns Python subproce
Nick Coghlan added the comment:
Discoverability is definitely a problem - part of that is a docs issue, since
test.support is currently the only one mentioned in the prose docs.
One advantage to moving to a support subpackage is that we can lose the
"helper" suffix from the names, w
Nick Coghlan added the comment:
Yep, that's exactly the kind of hook I had in mind. That way the user can
decide for themselves what level of scrutiny they want to apply.
--
title: Eliminate the use of eval() in the logging config implementation ->
Improve the security m
Nick Coghlan added the comment:
The "release blocker" status comes from the test case I added in order to
demonstrate the ability to strip a new frame sequence without needing to modify
the C code.
Currently that test (failing to write the PYC file) fails with an IsADirectory
trac
Nick Coghlan added the comment:
Note that I don't think test.support itself should be broken up - I don't see
any good reason to split the current grab bag of functionality out into
submodules, so you'd just have support/__init__.py open instead.
This is really about giving us
Nick Coghlan added the comment:
Martin, this change has been specifically requested by me to better organise
all the support code that ISN'T in test.support.
That file is already huge, and I'm not going to make it even bigger with all
the test infrastructure needed for generating
Nick Coghlan added the comment:
As noted in the original post, this is a change which will be made once the 3.3
release is out the door. It's origin lies in the fact that one of the new
pkgutil tests currently lives in test_runpy because test_runpy has much better
infrastructure for that
Changes by Nick Coghlan :
--
dependencies: +Move test/support.py into a test.support subpackage
___
Python tracker
<http://bugs.python.org/issue15403>
___
___
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue15376>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Nick Coghlan :
--
dependencies: +Add temp_dir() and change_cwd() to test.support
___
Python tracker
<http://bugs.python.org/issue15376>
___
___
Pytho
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue15358>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
I've just gone through and made sure all the related issues are correctly
assigned to me.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
OK, after a bit of experimentation, it appears both 3.2 and 3.3 eventually get
annoyed if you mess about too much with __pycache__.
1. They're both fine if __pycache__ is entirely unwritable (they just silently
skip caching the bytecode)
2. 3.2 throws EOF
Nick Coghlan added the comment:
Looking at the actual code - I don't think it actually makes sense to strip the
frames in this case. Unlike the previous examples, it only comes up if someone
is doing something deliberately pathological, at which point a little noise in
the traceback i
Changes by Nick Coghlan :
Removed file:
http://bugs.python.org/file26573/issue15486_simplify_importlib_frame_removal.diff
___
Python tracker
<http://bugs.python.org/issue15
Nick Coghlan added the comment:
I was musing about backporting *all* the memoryview fixes, including the buffer
lifecycle ones. Antoine and Stefan rightly pointed out that was a bad idea, and
not necessary to address this problem.
So +1 for backporting just this specific fix, with the
Nick Coghlan added the comment:
Ah, the perils of email readers with quote folding and issue trackers without
it. The important part of Brett's email is that PEP 420 has started splitting
the meta path finder and path entry finder APIs, but importlib still uses a
single ABC for both of
New submission from Nick Coghlan:
In the review of #15295, Brett noted that the APIs of meta path finders and
path entry finders have now diverged substantially thanks to PEP 420, thus it's
rather dubious that they continue to share a single Finder ABC in importlib.
--
compo
Nick Coghlan added the comment:
#15502 records Brett concern about the merged ABC
--
___
Python tracker
<http://bugs.python.org/issue15295>
___
___
Python-bug
Nick Coghlan added the comment:
Nice detective work, Victor.
Can we turn that particular optimisation off? We use function addresses for
identification purposes in many more places than just this one. Having the
compiler merge different pointers just because the functions happen to have the
Nick Coghlan added the comment:
As far as the path importer goes, it's important to keep in mind there are
*four* different pieces in play:
1. The path importer itself
This is a meta path finder installed on sys.meta_path, which implements the
find_module API. It scans the supplied s
Nick Coghlan added the comment:
s/locate path entry finders/appropriate path entry handlers/
--
___
Python tracker
<http://bugs.python.org/issue15295>
___
___
Nick Coghlan added the comment:
As we want to eventually deprecate find_module in the PathEntryHandler API, I'd
suggest two new subclasses, MetaPathFinder and PathEntryHandler, both
inheriting from Finder.
Current path hooks would be updated to inherit from PathEntryHandler, meta path
Nick Coghlan added the comment:
No, the HOWTO should be separate. Having them in the same document makes for
something that is worse as both a tutorial and as an API reference (just look
at argparse).
Yes, that means there are three places to update (code, reference, tutorial).
There are
Changes by Nick Coghlan :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue15425>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
Thanks Eli, that looks like a great start to me.
And yeah, the separate vs integrated tutorial argument is an ongoing one that
isn't going to be resolved by this issue :)
--
___
Python tracker
Nick Coghlan added the comment:
Yes, the module docs should have the provisional notice. Good catch.
--
___
Python tracker
<http://bugs.python.org/issue14
Nick Coghlan added the comment:
I would largely use Brett's proposed interface for MetaPathFinder (but keep
the path argument optional) and his PathImporter interface for
PathEntryHandler.
Finder can then just become a legacy alias for MetaPathF
Nick Coghlan added the comment:
(With the draft docs now comitted, this issue is the home for thrashing out the
terminology. I'm not going to propose taking this to import-sig or python-dev,
because the bikeshed would end up being fuschia or pink-with-yellow-polkadots
or something)
Ho
Nick Coghlan added the comment:
Further thoughts:
1. Let's keep Finder as a generic base class for "things which find module
loaders", with its current implementation but an updated docstring and
documentation.
2. The reason both the MetaPathFinder and PathEntryHander ABCs n
Nick Coghlan added the comment:
Reading through What's New, I withdraw the suggestion of changing the "path
entry finder" term. It's just not worth the hassle.
That also simplifies things a lot. All that needs to change to make things
consistent:
1. Switch the docs over t
Nick Coghlan added the comment:
Reading the 3.3 What's New reminded me that we aren't really as free to
redefine this terminology as we might hope (or as I claimed on the previous
issue). We can still try, of course, but the PEP 302 naming scheme has been
around for 10 years, and
Nick Coghlan added the comment:
Fair point. However, the find_module() variant of the API isn't dead yet, so we
should still support it. find_module() likely won't die completely until 4.0.
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
Indeed, there are still a couple of Windows failures, but they aren't related
to this.
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org
New submission from Nick Coghlan:
test_multiprocessing failed on one of the XP buildbots with a permission error:
http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7223/steps/test/logs/stdio
The immediate rerun also failed, but the one at the end of the test run
succeeded
New submission from Nick Coghlan:
regrtest bailed out completely on one of the Windows 7 builders due to a
problem with accessing the temporary working directory:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/410/steps/test/logs/stdio
It's seems a
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15519>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
As a final attempt at giving the path import machinery the emphasis it
deserves without misusing the "importer" term, how about:
1. "path import subsystem" for that whole section of the import machinery;
and
2. "path import finder"
Nick Coghlan added the comment:
The problem with "path importer" is it's just plain *wrong*. That object is
not an importer and thus calling it one makes it much harder to learn the
finder/loader/importer distinctions correctly. "import finder" is only
slightly longer th
Nick Coghlan added the comment:
As far as "path import finder" goes, it's no more wrong than "meta path finder"
and "path entry finder". A "meta path finder" is a finder that gets installed
on sys.meta_path, a "path entry finder" is one
3401 - 3500 of 6301 matches
Mail list logo
