[issue1764407] The -m switch does not use the builtin __main__ module
Nick Coghlan added the comment: Fixed committed to SVN as r57461 -- resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1764407 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1056] test_cmd_line starts python without -E
Nick Coghlan added the comment: Fixed for 2.6 in rev 58103 (Is the head still being merged to the py3k branch? Or does this need to be forward-ported manually?) -- nosy: +ncoghlan resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1056 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739468] Add a -z interpreter flag to execute a zip file
Nick Coghlan added the comment: I like PJE's approach, and the patch works for me. About the only thing I'd change is to switch the expression in PyImport_GetImporter to a simple chain of if-statements in order to: - silence the warning from GCC about an unused value - make it more obvious to a reader what the function is doing An optimising compiler is going to produce similar code either way, and it took me a moment to realise that the operations are being used purely for their short-circuiting effect, even though there is no real advantage to using an expression instead of a statement at that point in the code. Adding a simple test of the functionality to test_cmd_line would also be good. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1739468 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9732] Addition of getattr_static for inspect module
Changes by Nick Coghlan ncogh...@gmail.com: -- versions: +Python 3.2 -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9969] tokenize: add support for tokenizing 'str' objects
Nick Coghlan ncogh...@gmail.com added the comment: The idea is bring the API up a level, and also take care of wrapping the file-like object around the source string/byte sequence. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10220] Make generator state easier to introspect
Nick Coghlan ncogh...@gmail.com added the comment: I'll actually go with version 1 of the patch as far as the variable initialisation goes. Yes, it is fractionally slower, but you get a maintenance gain from the fact that the enum values are guaranteed to be orthogonal, and this is clearly obvious to the reader. When you write the assignments out explicitly, the reader has to actually look at the assigned values to determine whether or not the same value is ever assigned twice. (No need to post a modified patch - I'll fix it before I check it in) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10220 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10220] Make generator state easier to introspect
Nick Coghlan ncogh...@gmail.com added the comment: Committed in r86633. I added the missing docs changes, and tweaked the tests a little bit: - added a helper method to retrieve the generator state in the test case - this allowed test_running to be simplified a bit - added an explicit test for the CREATED-CLOSED case - renamed the test functions to match the existing idiom in test_inspect -- resolution: - accepted stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10220 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10220] Make generator state easier to introspect
Nick Coghlan ncogh...@gmail.com added the comment: Temporarily reopening to remind me to switch from using integer constants to strings (which are much friendlier for debugging purposes). -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10220 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Nick Coghlan ncogh...@gmail.com added the comment: Regarding question 1 (_start_server docstring): I have no problem with docstrings on private functions in general. It just means they're for the benefit of developers of the module itself rather than users of the module. However, in this case, I would move the example use out of the docstring and into a comment following the docstring. Regarding questions 2 5 (code structure and deprecations): This whole patch would have been a *lot* easier if the server and GUI implementations in pydoc had been properly private from the start. A look at the docs makes it fairly obvious that these are meant to be implementation details of the command line invocation, but the way they were written meant they were exposed as a public standard library API. As a result, we have to jump through a lot of hoops to replace them with the new back end. Since we don't want to maintain the old GUI client or the associated web server backend, the deprecations are needed so we can delete them entirely in 3.3. The situations Raymond is talking about are cases where we come up with a better API, but an old API is popular and not really all that flawed within its original scope (e.g. getopt vs optparse vs argparse). In such cases, deprecation gains us little and causes a lot of hassle. However, in a case like this, where people shouldn't have been using the old API anyway and there's a mountain of code we want to get rid of, deprecating the associated API is the right thing to do. The nested code structure is a reaction to the concern that caused all the additional difficulty - by squirreling all the implementation details away inside a small number of functions that are named with leading underscores, we eliminate the temptation to rely on the current location of these classes. For 3.3, I'd like to pursue Ron's idea of pulling the text server out and placing it in http.server for general use, with pydoc then retrieving it from there. Regarding questions 3 4 (repetition of bltinlink and HTML dodginess): Those two sound like issues that should be fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10586] Enhanced cache access API for functools.lru_cache
New submission from Nick Coghlan ncogh...@gmail.com: As per private email to Raymond, I would like to move the lru_cache access attributes and methods into a CacheInfo class, exposed as a cache attribute with several methods and read-only properties. Read-only properties: hits, misses, maxsize Methods: clear(), __len__() As an implementation detail, cache_misses and cache_hits become nonlocal variables rather than attributes of the wrapper function. Priority set to high, since the current API will be locked in as soon the first beta goes out. -- assignee: rhettinger files: functools_lru_cache_introspection.diff keywords: patch messages: 122879 nosy: georg.brandl, ncoghlan, rhettinger priority: high severity: normal status: open title: Enhanced cache access API for functools.lru_cache versions: Python 3.2 Added file: http://bugs.python.org/file19880/functools_lru_cache_introspection.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10586 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10586] Enhanced cache access API for functools.lru_cache
Nick Coghlan ncogh...@gmail.com added the comment: Raymond suggested a simple cache_info() method that returns a named tuple as a possible alternative. I like that idea, as it makes displaying debugging information (the intended use case for these attributes) absolutely trivial: import functools @functools.lru_cache() ... def f(x): ... return x ... f.cache_info() lru_cache_info(maxsize=100, currsize=0, hits=0, misses=0) (Alternative patch attached) -- Added file: http://bugs.python.org/file19882/functools_lru_cache_info_method.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10586 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10586] Enhanced cache access API for functools.lru_cache
Nick Coghlan ncogh...@gmail.com added the comment: Committed in r86878. I put a XXX note in the relevant part of the 3.2 What's New rather than updating it directly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10586 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10586] Enhanced cache access API for functools.lru_cache
Changes by Nick Coghlan ncogh...@gmail.com: -- stage: - committed/rejected status: open - closed type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10586 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10220] Make generator state easier to introspect
Nick Coghlan ncogh...@gmail.com added the comment: Switched to strings in r86879. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10220 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally
Nick Coghlan ncogh...@gmail.com added the comment: New patch which addresses my last two comments (i.e. some basic explicit tests of the encode/decode methods on result objects, and urldefrag returns a named tuple like urlsplit and urlparse already did). A natural consequence of this patch is that mixed arguments (as in the message above) will be rejected with TypeError. Once I figure out what the docs changes are going to look like, I'll wrap this all up and commit it. -- Added file: http://bugs.python.org/file19883/issue9873_just_needs_docs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally
Nick Coghlan ncogh...@gmail.com added the comment: Committed in r86889 The docs changes should soon be live at: http://docs.python.org/dev/library/urllib.parse.html If anyone would like to suggest changes to the wording of the docs for post beta1, or finds additional corner cases that the new bytes handling can't cope with, feel free to create a new issue. -- resolution: - accepted stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10593] LRU Cache with maxsize=None
Nick Coghlan ncogh...@gmail.com added the comment: Nice! You may still need to use the lock even for the simple unbounded case though - incrementing hits and misses isn't atomic, so the statistics may be miscounted if you get a hit or miss in different threads at the same time. Alternatively, we could just document the hit/miss statistics as approximate figures for tuning purposes rather than guaranteeing 100% accuracy in all situations. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9573] importing a module that executes fork() raises RuntimeError
Nick Coghlan ncogh...@gmail.com added the comment: Fixed for 3.2 in r86928. The fix has not been backported to 3.1, since it depends on the fix for issue 7242 (r78527) which was itself never backported to 3.1 after being forward ported to the py3k branch as part of a bulk merge (r83318) Backporting to 2.7 would also be a manual process (although much easier, since issue 7242 is already fixed in that branch) Given the obscurity of the error, I'm going to close this as fixed without backporting it. Anyone that wants it fixed in the 2.7 and 3.1 maintenance branches is free to develop and post the requisite patches :) -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Nick Coghlan ncogh...@gmail.com added the comment: Committed in r86962. Thanks to all involved in getting this from initial submission to final checkin :) Any further changes (including addressing Éric's last few comments) can be undertaken as separate issues. -- resolution: - accepted stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Nick Coghlan ncogh...@gmail.com added the comment: Oh, I also fixed in issue in both the old and new server code that switched warnings off globally rather than merely for the operation it was trying to disable warnings for. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: I brought the patch up to date for the Py3k branch, but realised just before checking it in that it may run afoul of the language moratorium (since it alters the behaviour of builtin range objects). However, the .count() and .index() methods (along with the Sequence ABC registration) as well as the O(1) containment testing for integers were already put in place. (I also noticed that the new methods from issue #9213 are not mentioned in the range() docs, unlike the O(1) optimisation) I've gone ahead and checked it in as r86970, as I see this patch as filling out the promise of the Sequence ABC registration by adding support for slicing and negative indices (with the length caching as more of an implementation detail). However, I'm also leaving the tracker issue open and assigning to Georg in case he wants to revert it before the beta goes out. Note that I also fixed the patch so that OverflowError occurs only when encountering an affected operation (primarily indexing and retrieval of the length). If you don't do any of those things, you can make your ranges as large as you like. (The indexing could fairly easily be fixed to eliminate the overflow errors - I just didn't do it in this patch, since it is a separate problem). -- assignee: - georg.brandl nosy: +georg.brandl resolution: - accepted stage: patch review - committed/rejected title: Precompute range length - Precompute range length and enhance range subscript support Added file: http://bugs.python.org/file19926/issue2690_lazy_overflow_check.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Nick Coghlan ncogh...@gmail.com added the comment: Added the missing CSS file in r86971. Hopefully that will make the buildbots a little happier. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Nick Coghlan ncogh...@gmail.com added the comment: r86975 should fix the problem with Windows paths. I also found an issue where many of the emitted HTML pages contained two HTML header sections. The tests were just written in a way that they only looked at the second of these header sections, while my browser only looked at the first. The same commit adjusts the tests to look at the first emitted header section and changes the flow in the URL handler to only ever invoke html.page() once per request. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2001] Pydoc interactive browsing enhancement
Nick Coghlan ncogh...@gmail.com added the comment: Oh, that would be Éric's point 4 that I fixed. OK, no need to create a new issue for that one then :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: On Sat, Dec 4, 2010 at 2:26 AM, Daniel Stutzbach rep...@bugs.python.org wrote: Daniel Stutzbach stutzb...@google.com added the comment: (I also noticed that the new methods from issue #9213 are not mentioned in the range() docs Wasn't that fixed in Issue9746? Ah, I see what you mean. I was more referring to the lack of a versionchanged note on the range() documentation itself, rather than the mentioning of range() under the sequence types documentation. Some of my new additions to the range documentation could probably be deleted and replaced with a reference to that part of the docs. Cheers, Nick. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: Daniel Stutzbach pointed out that range() is also mentioned under: http://docs.python.org/dev/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range The descriptions of range's limitations there is no longer accurate (slicing is supported following this patch and containment testing is now efficient) -- assignee: georg.brandl - status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: (Oops, didn't mean to reclose this yet) I want to wait for Georg's verdict on including the functionality in 3.2 before stressing too much about correct documentation of it :) -- assignee: - georg.brandl status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Nick Coghlan ncogh...@gmail.com added the comment:
To get back to my original objection, it shouldn't be that difficult to
differentiate between __context__ never set and __context__ explicitly
suppressed.
(e.g. using a property that sets an internal flag when set from Python code or
via PyObject_SetAttr, or else a special ExceptionContextSuppressed singleton).
BaseException could then be given a no_context class method that did whatever
dancing was necessary to suppress the context.
So Steven's examples would become:
def process(iterable):
try:
x = next(iterable)
except StopIteration:
raise ValueError.no_context(can't process empty iterable)
continue_processing()
def func(x):
try:
x + 0
except (ValueError, TypeError):
raise MyException.no_context('x is not a number')
do_something_with(x)
With appropriate changes to the exception display code, no_context could be as
simple as the C equivalent of the following:
@classmethod
def no_context(cls, *args, **kwds):
exc = cls(*args, **kwds)
exc.__context__ = ExceptionContextSuppressed
return exc
Another alternative would be an additional internal flag queried by the
exception chaining code itself:
@classmethod
def no_context(cls, *args, **kwds):
exc = cls(*args, **kwds)
exc.__context__ = None
exc._add_context = False
return exc
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10626] test_concurrent_futures implicitly installs a logging handler on import
Nick Coghlan ncogh...@gmail.com added the comment: This is unrelated to issue 10517 (based on Dave Malcolm's initial investigation, that looks like it may be a genuine problem in multiprocessing) Instead, this relates to a problem in concurrent.futures where it installs a logging *handler* as a side effect of import. IMO, this is itself a bug in the concurrent.futures package - the standard library shouldn't be installing logging handlers implicitly, but only when explicitly asked to do so, or when absolutely necessary (multiprocessing is an example of a package that walks this line appropriately). The reason the test_pydoc, test_logging, test_concurrent_futures sequence causes an error is as follows: 1. test_pydoc walks the entire package hierarchy when testing its ability to generate the HTML for the search page. 2. this implicitly imports concurrent.futures, since it is implemented as a package that imports names from submodules in __init__.py 3. this means the c.f handler is already registered in logging when test_logging is run 4. as test_logging assumes it has full control over the logging state, the c.f handler is not left in the same state as it started in 5. test_concurrent_futures then fails, as it assumes the state of the handler has not changed since it was created as a side-effect of the package import Quite a trip down the rabbit hole to figure that one out :) Handing back to Brian to fix the underlying problem (i.e. the implicit installation of the logging handler by concurrent.futures). Georg FYI as to why the py3k buildbots will sometimes go red if the randomised execution happens to run these 3 tests in this particular order (and my apologies for checking in the regrtest.py changes during the release freeze). -- assignee: ncoghlan - bquinlan keywords: +buildbot nosy: +georg.brandl title: test_concurrent_futures failure - test_concurrent_futures implicitly installs a logging handler on import ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10626] test_concurrent_futures implicitly installs a logging handler on import
Nick Coghlan ncogh...@gmail.com added the comment: For 3.2, writing such errors directly to stderr would be fine (we already do that in other places via PyErr_WriteUnraisable) The test could then be modified to use test.support.captured_output to temporarily replace stderr and look at the output. The problem of avoiding interfering with application level handlers while having unraisable errors visible by default is probably the biggest reason past attempts to get the standard library using the logging module internally haven't gained much traction :P -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10482] subprocess and deadlock avoidance
Nick Coghlan ncogh...@gmail.com added the comment: The general idea is sound. My work colleagues have certainly had to implement their own reader/writer thread equivalents to keep subprocess from blocking. It makes sense to provide more robust public support for such techniques in process itself. -- nosy: +ncoghlan versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10626] test_concurrent_futures implicitly installs a logging handler on import
Nick Coghlan ncogh...@gmail.com added the comment: Actually, I take it back. The default state of logging appears to do the right thing with no special handler installed - both the .critical() and .exception() messages are written out to stderr by default, so the futures tests pass even after Brian's patch is applied. So I think removing the handler installation code is the right thing to do, even if (as it turns out) it doesn't fix the test failure. I also thought of a more minimal way to reproduce the test failure that makes it clear pydoc isn't really involved: ./python -m test test_concurrent_futures test_logging test_concurrent_futures The first execution of the test will pass, the second will fail (both with and without Brian's patch to remove the handler installation). Adding Vinay to the nosy list - I suspect Antoine is right that the logging tests are leaving existing loggers in a slightly unhealthy state. A better save/restore in regrtest.py might be a place to start, but I don't know the internals of the logging package well enough to improve on what I already added. -- nosy: +vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10626] Bad interaction between test_logging and test_concurrent_futures
Changes by Nick Coghlan ncogh...@gmail.com: -- title: test_concurrent_futures implicitly installs a logging handler on import - Bad interaction between test_logging and test_concurrent_futures ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10482] subprocess and deadlock avoidance
Nick Coghlan ncogh...@gmail.com added the comment: Or various incarnations of functools.partial applied to subprocess.Popen. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10626] Bad interaction between test_logging and test_concurrent_futures
Nick Coghlan ncogh...@gmail.com added the comment: Yeah, I think that comment was just a mistaken impression on my part. Definitely something odd going on with the test interaction though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10626 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: The other major change for ranges is that in and not in are no longer inefficient for actual instances of int (it does an arithmetic calculation instead of a linear search). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length and enhance range subscript support
Nick Coghlan ncogh...@gmail.com added the comment: No, I believe it was added as part of the .index() and .count() implementation. Checking the source, there's definitely no sq_contains implementation in 3.1 or 2.7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2690 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10677] make altinstall includes ABI codes in versioned executable name
New submission from Nick Coghlan ncogh...@gmail.com: make altinstall is currently installing python3.2m rather than python3.2. Since PEP 3149 makes no mention of changing the executable name, this should be fixed to correctly install the executable as python3.2. I suspect this will also affect a make install, but will be obscured in that case since the python3 symlink will still do the right thing. (I haven't tried it, since I don't want to clobber the Canonical provided 3.1 installation) -- assignee: barry messages: 123782 nosy: barry, georg.brandl, ncoghlan priority: release blocker severity: normal status: open title: make altinstall includes ABI codes in versioned executable name versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10677] make altinstall includes ABI codes in versioned executable name
Changes by Nick Coghlan ncogh...@gmail.com: -- components: +Build stage: - needs patch type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10679] make altinstall will clobber OS provided scripts
New submission from Nick Coghlan ncogh...@gmail.com: make altinstall installs 2to3, pydoc3 and idle3 without version specific names. This was at least a deliberate decision in the case of 2to3, but there doesn't appear to be any reason not to use a properly qualified version suffix on the pydoc and idle executables. -- messages: 123784 nosy: benjamin.peterson, georg.brandl, ncoghlan priority: release blocker severity: normal stage: needs patch status: open title: make altinstall will clobber OS provided scripts type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10679] make altinstall may clobber OS provided scripts
Nick Coghlan ncogh...@gmail.com added the comment: Softened the wording, since OS packages will often omit installing any executable files other than the main python binary. -- title: make altinstall will clobber OS provided scripts - make altinstall may clobber OS provided scripts ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10677] make altinstall includes ABI codes in versioned executable name
Nick Coghlan ncogh...@gmail.com added the comment: The other thing that makes this clearly an error is, of course, the fact that all the shebang lines expect the executable to be called python3.2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Nick Coghlan ncogh...@gmail.com added the comment: I have a slightly better fix for that coming soon. There's a subtle race condition in the proposed approach that can lead to the temporary dir not being deleted if an asynchronous exception, such as KeyboardInterrupt, arrives after mkdtemp completes successfully, but before _closed is set back to False. Instead, the new init code will look like: self._closed = False self.name = None # Handle mkdtemp throwing an exception self.name = mkdtemp(suffix, prefix, dir) And the cleanup condition will be gated on self.name being set as well as on _closed being False. I believe there is still a window where mkdtemp successfully creates the directory, but self.name never gets set, but we want to make that window as small as possible. I also realised this should be emitting a ResourceWarning from __del__, as well catching the errors and shut down and turning them into something more meaningful on sys.stderr. The attached patch won't quite apply cleanly, since it predates r87172 -- keywords: +patch Added file: http://bugs.python.org/file20022/issue10888_tempdir_cleanup.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Nick Coghlan ncogh...@gmail.com added the comment: Although it may be better to just raise a new, more meaningul, exception and let the runtime take care of ignoring it (since it happens in __del__) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9232] Allow trailing comma in any function argument list.
Changes by Nick Coghlan ncogh...@gmail.com: -- stage: needs patch - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Nick Coghlan ncogh...@gmail.com added the comment: Tidy ups committed in r87182. Shutdown problems now result in a slightly more meaningful message on stderr, a ResourceWarning is triggered when an implicit teardown occurs and the chances of an AttributeError due to an exception in __init__ are minimised. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Nick Coghlan ncogh...@gmail.com added the comment: Sorry, I realised after I had logged off and gone to bed that I hadn't finished the last test. Fixed in r87204 with an approach that should exercise the relevant behaviour regardless of platform. The commit message has also been updated to refer to the correct issue. I'm actually going to close this now - the problem of misbehaviour due to modules being nulled out at shutdown is a more universal problem being tracked elsewhere, and I think the behaviour I just added is the best we can hope for until that is fixed. -- resolution: - fixed status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
Nick Coghlan ncogh...@gmail.com added the comment: Ah, yes, I failed to account for the additional string escaping performed by the IO stream. I think I've been bitten by that before, but I always forget since I try to always use forward slashes for paths, even on Windows. r87212 modifies the test to ensure that failure mode is encountered on non-Windows systems as well and correctly reverses the escaping in the test when reading the message back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9232] Allow trailing comma in any function argument list.
Nick Coghlan ncogh...@gmail.com added the comment: An open issue more accurately reflects the lack of consensus than a closed one, though. We just won't commit it until there *is* consensus that it is a better option than the status quo. -- keywords: +after moratorium -patch resolution: rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10682] With '*args' or even bare '*' in def/call argument list, trailing comma causes SyntaxError
Changes by Nick Coghlan ncogh...@gmail.com: -- resolution: rejected - duplicate superseder: - Allow trailing comma in any function argument list. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9232] Allow trailing comma in any function argument list.
Nick Coghlan ncogh...@gmail.com added the comment: From 10682: the grammar is also inconsistent as to when trailing commas are allowed in function calls, not just definitions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9232 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9990] PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
Nick Coghlan ncogh...@gmail.com added the comment: The PEP is quite clear that the object providing the buffer owns those fields. Last time I checked, the memoryview implementation appeared broken because it didn't respect that ownership (and created the potential for confusion on the topic). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10725] Better cache instrumentation
Nick Coghlan ncogh...@gmail.com added the comment: Indeed, getsizeof() on containers only gives the amount of memory consumed by the container itself (this can be difficult to figure out externally for potentially sparse containers like dicts), but leaves the question of the size of the referenced objects open. Exposing the result of sys.getsizeof() on the cache may not be a bad idea, but the question would be which use cases are handled by that additional information which aren't adequately covered by the simple count of the cache entries. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10747] Include version info in Windows shortcuts
New submission from Nick Coghlan ncogh...@gmail.com: This issue is to propose specific wording to Martin for inclusion of version details in the Windows shortcuts. This is to make the shortcuts easier to use when the hierarchical menu information is lost for any reason (e.g frequently used program list, searching the start menu, copied to desktop). Shortcuts currently installed: - Python (command line) - Python Manuals - Module Docs - IDLE (Python GUI) - Uninstall Python Initial proposal for 32 bit builds: - Python 3.2 (command line - 32 bit) - Python 3.2 Manuals - Python 3.2 Docs Server (pydoc - 32 bit) - IDLE (Python 3.2 GUI - 32 bit) - Uninstall Python 3.2 (32 bit) Initial proposal for 64 bit builds: - Python 3.2 (command line - 64 bit) - Python 3.2 Manuals - Python 3.2 Docs Server (pydoc - 64 bit) - IDLE (Python 3.2 GUI - 64 bit) - Uninstall Python 3.2 (64 bit) Any feedback/alternate suggestions/bikeshedding on the python-dev thread, please ;) -- messages: 124427 nosy: ncoghlan priority: normal severity: normal status: open title: Include version info in Windows shortcuts type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10747 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Nick Coghlan ncogh...@gmail.com added the comment: No, the context must always be included unless explicitly suppressed. The interpreter can't reliably tell the difference between a raise statement in the current exception handler and one buried somewhere inside a nested function call. The whole point is to give developers a hint as to how to trigger the broken error handling code, which only works if the default behaviour is to provide the additional information. Being able to suppress the context *is* a valid feature request, but one that will now need to wait until Python 3.3. In the meantime, sys.excepthook + the traceback module + PYTHONSTARTUP allows individual users to modify the interactive prompt to exhibit whatever exception display behaviour they like, and applications can do the same thing in their __main__module (likely via a context manager retrieved from a utility module). -- keywords: +after moratorium versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Nick Coghlan ncogh...@gmail.com added the comment: For can't tell in my previous message, read we aren't going to impose the requirement to be able to tell if an exception is being raised directly in the current exception handler as a feature of conforming Python implementations. We probably *could* tell the difference in CPython if we really wanted to. Even without considering that aspect, it would also be seriously odd if putting the exception raising into a helper function suddenly caused context information to be included that was otherwise implicitly suppressed. Much better to correctly support explicit suppression of the context as discussed earlier in the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9370] Add reader redirect from test package docs to unittest module
Nick Coghlan ncogh...@gmail.com added the comment: Yeah, I think I wrote this issue based on the diff that added the new note at the top, rather than looking at the existing intro text that already references unittest and doctest. No need to change anything after all. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: Agreed. I'll put something on python-dev about that, so MvL sees it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: More direct - added MvL to nosy list. Martin, we would like to exclude Py_buffer from the stable ABI for Python 3.2, until we have a chance to thrash out the missing pieces of the documentation for 3.3. I *think* it is a documentation problem, but until we're certain, it seems safer to leave it out. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10001] ~Py_buffer.obj field is undocumented, though not hidden
Nick Coghlan ncogh...@gmail.com added the comment: Closing as a dupe of 10181, but transferring Lenard's comments over there. -- resolution: - duplicate status: open - closed superseder: - Problems with Py_buffer management in memoryobject.c (and elsewhere?) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: From Lenard Lindstrom in issue 10001 (closed as dupe of this issue): The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a wrapper, includes the field in gc traversal. Also, if the field is not initialized by bf_getbuffer its value can be indeterminate. For memoryview the gc can crash (see attached C demo program). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: Added Travis to nosy list - even if he doesn't have time to finish this off himself, hopefully he can point us in the right direction. -- nosy: +teoliphant ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: PEP 3118 makes it clear that the underlying object should see *two* pairs of calls to the buffer methods: http://www.python.org/dev/peps/pep-3118/#the-py-buffer-struct Even if we ignore the undocumented obj field, the target object needs to ensure the exported buffer remains valid as long as any memory views are referencing it. The only way to do that is to treat GetBuffer/ReleaseBuffer as the moral equivalent of INCREF/DECREF. However, I believe the current memoryview implementation does the wrong thing and only calls them once, and then duplicates the Py_buffer structures without ever going back to the original objects (that opinion was based on a quick scan of the code a while back, but it would fit with the uncomplimentary sentiments Antoine has expressed in trying to get all this to exhibit some kind of consistency) For point 2, it must be the same pointer. When the PEP says the same, I agree it could be taken as ambiguous, but the later reference to the exporter managing a linked-list of exported views makes it clear that identity is what matters. As far as I can see, some of things in the PEP were found to be a PITA in practice (such as every consumer of the API having to implement the equivalent of the base attribute in the original memoryview design), so Travis changed them. Unfortunately, those changes never made it back into the protocol documentation, leading to the current confusion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: It's OK if the Py_buffer is on the stack - it's just a unique identifier for the exporter to use as a key, not something the exporter controls the lifecycle of (the latter is true only for the pointers *inside* the struct, such as buf, shape, strides, etc). PyMemoryView_FromBuffer should be calling PyObject_Getbuffer on the view-obj member (it's one of the things that embedding the reference allows, just as it allowed removal of the separate obj argument from the PyObject_ReleaseBuffer signature). That way the source object knows there is now a *second* Py_buffer struct kicking around, and can decide whether to re-use the same internal pointers or create new ones. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: Martin's patch for the PEP 384 adjustments looks good to me. A note in the PEP that we've deliberately excluded this on a temporary basis due to the implementation/documentation mismatch and expect to have it back in for 3.3 might be helpful, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: @Antoine: I actually had a closer look at the way dup_buffer is used, and I think it is currently legitimate (including for the anonymous memory case). It just isn't documented very well. For the FromBuffer case, it assumes the calling code already invoked GetBuffer as necessary when initialising the view, and for the various internal uses the dup_buffer call is immediately preceded by a GetBuffer call when view-obj is not NULL. @Mark: I don't think that follows. PEP 3118 says that exporting objects own that memory, but it doesn't say that clients have to treat the structures as read-only. The only thing clients are obligated to do is pass the same Py_buffer address to ReleaseBuffer that was passed to GetBuffer. If the exporter actually needs to release buffer specific resources, then it should maintain an internal data structure keyed off the Py_buffer address. The one thing clients really shouldn't mess with is the obj field (since ReleaseBuffer needs that to find the correct release method to invoke), but the PEP is obviously silent on that matter since it doesn't even acknowledge the existence of that field. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10845] test_multiprocessing failure under Windows
Nick Coghlan ncogh...@gmail.com added the comment: I'm curious as to the results you get running python -m test.__main__ and python Lib/test/__main__.py as well. I suspect both will fail. Looking at the forking.py code, I think multiprocessing makes some assumptions that are flat out invalid in the presence of the -m switch - there are no guarantees that you can reverse engineer the name of an arbitrary module from the __file__ attribute. (This actually ties in with the current thread on python-ideas about making the real name of the main module readily available - then the parent process could just pass that through the pipe as a main_name value and this problem would go away) In the short term, however, I think multiprocessing just needs to either special case the situation where main_name actually *is* __main__ or just drop the assertion across the board. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: It only needs to be unique for the lifetime of the buffer reference - for a Py_buffer struct on the stack, by the time the relevant C stack frame goes away, ReleaseBuffer should already have been called. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9990] PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
Nick Coghlan ncogh...@gmail.com added the comment: As per the discussion over in issue #10181, I've changed my position on this issue. Since the PEP isn't explicit on the exact semantics here, I think we should be guided by the memoryview behaviour and make it official that bf_releasebuffer implementations shouldn't trust the contents of the passed in Py_buffer struct. Instead, if that information is important, the exporter should create an internal data structure that preserves the necessary detail and merely use the Py_buffer address as an identifier to locate the internal copy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9990] PyMemoryView_FromObject alters the Py_buffer after calling PyObject_GetBuffer when ndim 1
Nick Coghlan ncogh...@gmail.com added the comment: The alternative (if we declare that clients should treat Py_buffer contents as completely read-only) is to update memoryview to include a separate orig_view field that would never be touched. The GetBuffer and ReleaseBuffer calls would then use orig_view, with dup_buffer used to copy the data into the main view field before modifying it. However, this approach greatly complicates the bf_getbuffer and bf_releasebuffer implementations, since memoryview could no longer pass the supplied Py_buffer pointer straight through to the underlying implementation. Instead, for each call to bf_getbuffer, it would need to create a new Py_buffer struct, use that for the GetBuffer call to the underlying object, copy the contents over to the passed in buffer (modifying the shape information as appropriate for any slicing that is in effect), then, in bf_releasebuffer, use the passed in pointer to find the right Py_buffer struct to use in the ReleaseBuffer call. Putting the onus on exporters to be suspicious of the contents of the Py_buffer objects handed to bf_releasebuffer implementations actually seems like the more robust approach in the long run. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: Ah, sorry - no, I misunderstood the question. I think that example actually *is* a bug in the memoryview implementation. The GetBuffer call should use the persistent address (mview-view) that will be used in the ReleaseBuffer call, as per Antoine's patch on issue 9990. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10859] Is GeneratorContextManager public?
Nick Coghlan ncogh...@gmail.com added the comment: I'd like to leave the door open to some tweaks in the GCM implementation for 3.3, so making it officially private (by adding the leading underscore) sounds good to me. -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10859 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9904] Cosmetic issues that may warrant a fix in symtable.h/c
Nick Coghlan ncogh...@gmail.com added the comment: If I recall correctly, st_nblocks and st_future are there for consistency with the corresponding compiler structures. I believe st_future is also needed whenever a future flag affects the symtable construction (there aren't any at the moment, but a trawl through the version history in the Python 2.x symtable.c may reveal some) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10556] test_zipimport_support mucks up with modules
Nick Coghlan ncogh...@gmail.com added the comment: Even more special: put a test_doctest in first and the attempt to clean up sys.modules in test_zipimport_support leaves things alone so the _ssl module doesn't break (test_doctest just leaves sys.modules alone and doesn't even try to remove all the modules it implicitly imports). I'm actually tempted to remove test.support.modules_setup() and modules_cleanup() and delete the calls from the affected tests. Trying to clear out implicitly imported modules is going to create far more problems than it resolves. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10556] test_zipimport_support mucks up with modules
Nick Coghlan ncogh...@gmail.com added the comment: Fixed for 3.2 in r87925. (I simply dropped the attempt to restore sys.modules to its original state from test_zipimport_support) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10556] test_zipimport_support mucks up with modules
Nick Coghlan ncogh...@gmail.com added the comment: 2.7 and 3.1 don't appear to exhibit the fault, so closing this one. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10889] Fix range slicing and indexing to handle lengths sys.maxsize
New submission from Nick Coghlan ncogh...@gmail.com: Enhancement to range to correctly handle indexing and slicing when len(x) raises OverflowError. Note that this enables correct calculation of the length of such ranges via: def _range_len(x): try: length = len(x) except OverflowError: step = x[1] - x[0] length = 1 + ((x[-1] - x[0]) // step) return length -- assignee: ncoghlan messages: 126017 nosy: ncoghlan priority: normal severity: normal status: open title: Fix range slicing and indexing to handle lengths sys.maxsize ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10889] Fix range slicing and indexing to handle lengths sys.maxsize
Nick Coghlan ncogh...@gmail.com added the comment: Having started work on this, the code changes are probably too significant to consider adding it to 3.2 at this late stage. Writing my own slice interpretation support which avoids the ssize_t limit is an interesting exercise :) -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10889] Fix range slicing and indexing to handle lengths sys.maxsize
Nick Coghlan ncogh...@gmail.com added the comment: Attached patch moves range indexing and slicing over to PyLong and updates the tests accordingly. Georg, I think this really makes the large range story far more usable - if you're OK with it, I would like to check it in this week so it lands in 3.2. -- assignee: ncoghlan - georg.brandl keywords: +patch nosy: +georg.brandl versions: +Python 3.2 -Python 3.3 Added file: http://bugs.python.org/file20355/issue10889_range_subscripts.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10889] Fix range slicing and indexing to handle lengths sys.maxsize
Nick Coghlan ncogh...@gmail.com added the comment: Oh, and to explain my negative comment from earlier: that was my reaction when I realised I also needed to write PyLong versions of _PyEval_SliceIndex and PySlice_GetIndicesEx to make range slicing with large integers work properly. As it turned out, the end result wasn't as scary as I initially feared (while compute_slice_indices is quite long, most of that is just the verbosity of PyLong arithmetic). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10889] Fix range slicing and indexing to handle lengths sys.maxsize
Nick Coghlan ncogh...@gmail.com added the comment: Committed as r87948. I added a few large_range tests to those in the patch. I checked that IndexError is raised when appropriate, as well as a specific test for the combination of a large range with a large negative step. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10889] Fix range slicing and indexing to handle lengths sys.maxsize
Changes by Nick Coghlan ncogh...@gmail.com: -- resolution: - accepted stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9844] calling nonexisting function under __INSURE__
Nick Coghlan ncogh...@gmail.com added the comment: A quick Google search suggests that code is there to make Insure++ happy, so +1 for Eli's simple fix. Georg hasn't closed the py3k branch yet, so go ahead and commit it. (3.2c1 is due this Saturday, so it's worth keeping a close eye on python-committers for the freeze notice - time zones means the relative timing of things can be surprising) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10902] Doc type: run_* instead of run* on http://docs.python.org/library/pdb.html
Nick Coghlan ncogh...@gmail.com added the comment: Yep, go ahead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10902] Doc type: run_* instead of run* on http://docs.python.org/library/pdb.html
Nick Coghlan ncogh...@gmail.com added the comment: Ah, true - I forgot svnmerge for 27-maint was based on the py3k branch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10854] Output DLL name in error message of ImportError when DLL is missing
Nick Coghlan ncogh...@gmail.com added the comment: As Martin says, we aren't inclined to implement or maintain the equivalent of depends.exe in order to provide a slightly better error message. If anyone wants to reopen this issue, provide a patch. Otherwise devs are just going to close it again. Optionally, campaign for a fix on python-list and see if you can persuade someone *else* to provide a patch. You could even go to the source of the problem and ask *Microsoft* to provide a better error message. -- nosy: +ncoghlan status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10854] Output .pyd name in error message of ImportError when DLL load fails
Nick Coghlan ncogh...@gmail.com added the comment: Sorry, I missed that the request had changed to just the .pyd name. That at least is useful, since you then know where to start with depends.exe. It should be fairly straightforward to implement as well. Adjusted issue title accordingly. -- resolution: wont fix - status: closed - open title: Output DLL name in error message of ImportError when DLL is missing - Output .pyd name in error message of ImportError when DLL load fails ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Nick Coghlan ncogh...@gmail.com added the comment: For the record, the gory details as to *why* RichCompareBool makes more assumptions as to the meaning of equality than the basic RichCompare function can be found in issue 4296 (I just found that issue myself by looking at Mark's response to the python-list thread). It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Nick Coghlan ncogh...@gmail.com added the comment: Yeah, to prevent perfectly reasonable why questions, it is probably worth providing a little extra justification as an addendum to your new note (which is already an improvement on the complete silence on the topic that existed before). A possible addition: ... This assumption allows invariants such as x in [x] to be more easily guaranteed by the interpreter. If the assumption is not valid for a given use case, call PyObject_RichCompare() directly instead of using this function. For 3.3, it *may* make sense to provide a PyObject_RichCompareBoolEx() function which includes an additional reflexive parameter. Then the existing PyObject_RichCompareBool() semantics would just be the new function with the reflexive argument set to 1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: A TLS based approach would presumably allow an embedding application like mod_wsgi to tinker with the state of threads created by naive modules that are unaware of the existence of subinterpreters. That said, I don't see anything that prevents us from pursuing a TLS based override for the existing PyGILState functions later if the simpler, more explicit approach proves inadequate. As it stands, the new explicit calls allow something like mod_wsgi to define its *own* TLS location for the interpreter that is currently handling callbacks into Python, then use SWIG to generate PyGILState_*Ex calls in callback wrappers that reference that TLS interpreter state. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Nick Coghlan ncogh...@gmail.com added the comment: Indeed. I was actually wondering if it would be worth trying to write up a section for the language reference to describe the cases where a Python implementation is *expected* to assume reflexive equality. We (IMO) have a problem at the moment due to situations like: class PyContains(list): ... def __contains__(self, obj): ... return any(x==obj for x in self) ... nan = float(nan) nan in [nan] True nan in PyContains([nan]) False This is a bug in the __contains__ definition (it should use x is obj or x == obj rather than just the latter expression) but there isn't anything in the language reference to point that out. Assuming reflexive equality in some places and not in others based on the underlying implementation language is going to be a source of subtle bugs relating to types like float and decimal.Decimal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: There's no point improving the multiple interpreter support if it doesn't help applications that are currently broken because of that lack of support. I believe the patch as currently proposed actually makes things *worse*. With autoTLSkey as a static variable, all subinterpreters will use the same key to point into thread local storage (which is defined process-wide). This means they won't tread on each other's toes: the interpreter that creates a thread owns that thread. So Graham's simple use case *should already work*, as the creation of the thread by the subinterpreter will populate autoTLSkey with a valid thread state, which will then be used by calls back in to the GILState API. Looking at 3.2, there appear to be two ways for an application to get itself into trouble: 1. Hand off an OS level thread from the creating interpreter to a different subinterpreter. As far as I can tell, calling GILState_Ensure in such a thread will still acquire the GIL of the creating interpreter (or something equally nonsensical). I may be misreading that though - this isn't exactly the easiest part of the code base to follow :) 2. Native (non-Python) threads will always have their temporary thread state created in the main interpreter unless the application takes steps to precreate a thread state using a different interpreter. So, a new PyGILState_EnsureEx API may be beneficial regardless in order to help with part 2 of the problem, but I think it should be used solely as a way to override autoInterpreterState. autoTLSkey should be left alone so that a given OS level thread can only be owned by one interpreter at a time. Further, there is no need for any function with access to a valid thread state (i.e. _PyGILState_NoteThreadState, as well as PyGILState_Release if autoTLSkey remains a static variable) to take an interpreter argument. These functions can identify the relevant interpreter from the interp field of the thread state. TL;DR version: - I agree the compatibility between multiple interpreters and the GILState API can be improved - I agree a PyGILState_EnsureEx that takes an interpreter argument should be part of that solution. - I *disagree* with making autoTLSkey interpreter specific, as it seems to me that will make the situation worse rather than better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: Added Mark Hammond to the nosy list, as the original author and implementor of PEP 311 (which added the GILState APIs). Mark, since your PEP deliberately punted on multiple interpreter support, feel free to take yourself off the list again. If you spot any glaring errors in my post above it would be nice to know, though :) -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: Graham - the cases you describe are the things I was saying don't currently work in my post and wouldn't be helped by Antoine's patch. Your thoughts on how we could possibly make it work actually parallel mine (although there may be fun and games with making sure the respective GILs are acquired and released in an appropriate order when switching interpreters). However, if a given OS thread is created by a subinterpreter via thread_PyThread_start_new_thread, then the thread bootstrapping process will copy the thread state from that subinterpreter rather than the main interpreter. Accordingly, the only thing that I believe should currently work with subinterpreters is the naive use case you described earlier (i.e. a call out to an extension module from a Python created thread that later calls back in using the PyGILState API in the exact same thread should work even in the presence of multiple interpreters). This is the use case that I believe Antoine's patch as it currently stands actively *breaks* by making the autoTLSkey interpreter dependent. Regardless, I'm marking 10914 as a dependency of this one, as I don't think we should change anything in this area until we have some unit tests to properly define what does and doesn't work. If we're going to promote subinterpreters to a robust, fully supported feature we may as well do it right. -- dependencies: +Python sub-interpreter test ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10914] Python sub-interpreter test
Nick Coghlan ncogh...@gmail.com added the comment: I like the idea of adding these tests as well. Probably worth bringing up on python-dev - folks like Tarek should definitely be able to help with alternative ways of building a test application for this. There is also always the possibility of writing it in Python and using ctypes to get at the necessary C API calls to create subinterpreters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10926] Some Invalid Relative Imports succeed in Py 3.0 3.1 [ correctly fail in 3.2rc1]
Nick Coghlan ncogh...@gmail.com added the comment: Yeah, 7902 was a bug that tried to do an absolute import if an explicit relative import failed to find anything (i.e. it had inherited the old implicit relative import fallback, which was entirely inappropriate for the new use case). Since the significant import in these examples should correctly be written as from .. import Xpm, it should fail in 2.6.6 and 3.1.3 as well. If you could confirm that at least 3.1.3 also gives the expected error message, we'll close this as a dupe of 7902. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: Good point - consider that comment revised to refer to the GIL acquisition counter in the thread state struct. It may just be a matter of having ThreadState_Swap complain loudly if the gilstate_counter isn't set to a value it knows how to handle. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3080] Full unicode import system
Nick Coghlan ncogh...@gmail.com added the comment: Victor, could you please create a Reitveld review for this? The auto-review creator can't cope with the Git diffs. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3080] Full unicode import system
Nick Coghlan ncogh...@gmail.com added the comment: OK - I'll wait until that is ready before digging into this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3080] Full unicode import system
Nick Coghlan ncogh...@gmail.com added the comment: After applying the patch, doing a make clean and rebuild, I found that test_importlib fails with a segmentation fault, but the default test suite otherwise runs without error (that's on Linux with a UTF-8 filesystem, though). I'll see how a -uall run fares. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
