[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: Minimal patch attached (no niceties like NEWS or unit tests included yet) -- keywords: +patch Added file: http://bugs.python.org/file18551/issue9573_fork_on_import.diff ___ Python tracker <http://bugs.python.

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: Test script attached that demonstrates the underlying problem directly via imp.lock_held() (this could easily form the basis of a unit test) -- Added file: http://bugs.python.org/file18552/fork_on_import.py

[issue9567] Add attribute pointing to wrapped function in functools.update_wrapper

Nick Coghlan added the comment: Implemented in r84132 -- stage: unit test needed -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue3445] Ignore missing attributes in functools.update_wrapper

Nick Coghlan added the comment: Implemented in r84132 (not based on this patch though). -- stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue9147] dis.show_code() variant that accepts source strings (and returns rather than prints)

Nick Coghlan added the comment: Implemented in r84133 -- resolution: -> accepted stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.o

[issue9147] dis.show_code() variant that accepts source strings (and returns rather than prints)

Nick Coghlan added the comment: Final name was dis.code_info() and it accepts functions, methods, code objects and source strings. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9147] dis.show_code() variant that accepts source strings (and returns rather than prints)

Nick Coghlan added the comment: I changed the test to a regex match that ignores the specific ID value of the nested function in r84137. That should make the buildbots happier. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9147] dis.show_code() variant that accepts source strings (and returns rather than prints)

Nick Coghlan added the comment: Switching to a regex match made the backslashes in windows paths a problem. r84139 changes the test to just ignore all the variable info in the code_info results so we'll see how that goes. -- ___ Python tr

[issue8202] sys.argv[0] and python -m package

Nick Coghlan added the comment: Implemented in r84140. Leaving issue open until the buildbots give it a clean bill of health (since the command line tests can be a little quirky when it comes to cross platform differences) -- resolution: -> accepted stage: unit test nee

[issue9147] dis.show_code() variant that accepts source strings (and returns rather than prints)

Nick Coghlan added the comment: The windows buildbot still doesn't appear to be particularly happy, but this issue also doesn't appear to be the culprit anymore. -- status: open -> closed ___ Python tracker <http://bugs.pyth

[issue9627] Regrtest failed to clean up temporary directory

New submission from Nick Coghlan : Watching the Windows buildbot to check if test_dis was working yet, I found this output: http://www.python.org/dev/buildbot/stable/builders/x86%20XP-4%203.x/builds/2774/steps/test/logs/stdio It appears something still had files open in the directory when

[issue9627] Regrtest failed to clean up temporary directory

Nick Coghlan added the comment: The ref count over 1 million at the end of that output is also rather suspicious. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9627] Regrtest failed to clean up temporary directory

Nick Coghlan added the comment: Reading through the other issue, I think you're right. Closing as a duplicate of issue 7443. -- resolution: -> duplicate status: open -> closed superseder: -> test.support.unlink issue on Wi

[issue7443] test.support.unlink issue on Windows platform

Nick Coghlan added the comment: I closed issue 9627 as a duplicate of this - the buildbot failure referenced there was most likely due to something else holding open a temporary file that the test suite thought was closed. -- nosy: +ncoghlan

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: It turns out my proposed patch is incorrect anyway - it will do the wrong thing if a thread *other* than the one doing the fork is in the middle of a nested import at the time the fork occurs. With issue 7242 establishing that the current thread ID may not

[issue9573] importing a module that executes fork() raises RuntimeError

Nick Coghlan added the comment: On further further reflection - I'm back to thinking my patch is correct. With the way fork is now implemented, the forking thread *always* holds the import lock, so the assumption in my patch regarding the meaning of the nesting level is correct. It

[issue9157] Allow inspection of used decorators on a function

Nick Coghlan added the comment: How? It was easy for wraps to add the __wrapped__ attribute, since it has access to both the wrapping function and the function being wrapped. But it hasn't got a clue as to the identity of the decorator that is applying the wrapper. Absent a con

[issue9157] Allow inspection of used decorators on a function

Nick Coghlan added the comment: That's a lot of boilerplate for minimal gain. The Django commenter was right - proposals that start with "everybody in the world needs to do X differently from the way they do it now for this to be useful" aren't ever likely to

[issue9251] Test for the import lock

Nick Coghlan added the comment: With the new setUp and tearDown methods, the threadedimp2 patch doesn't apply cleanly any more. Looks good and passes for me - fixed patch attached. Was I meant to still be looking at mtimport or threadimp, or have both of those been ap

[issue1284670] Allow to restrict ModuleFinder to get "direct" dependencies

Nick Coghlan added the comment: The generalist in me is inclined to suggest a "depth" parameter (with depth=1 equivalent to direct dependencies only, and depth = None meaning all dependencies), but I must admit I don't have a concrete use case for the extra generality.

[issue1284670] Allow to restrict ModuleFinder to get "direct" dependencies

Nick Coghlan added the comment: Although I do find it a little concerning that there is no mention of sys.path_hooks or sys.meta_path in the modulefinder source code. I suspect this module only works correctly with vanilla filesystem based imports and can't handle anything imported vi

[issue9657] Add circular imports test

Nick Coghlan added the comment: It would be good if the test timed out rather than deadlocking in the face of a broken import lock. I suggest: 1. Make the two test threads daemon threads 2. Specify a timeout to the join() calls 3. Use self.assertFalse(t1.is_alive()) and self.assertFalse(t2

[issue9657] Add circular imports test

Nick Coghlan added the comment: Both good points - don't worry about it then. +1 to add to the test suite as-is. -- ___ Python tracker <http://bugs.python.org/i

[issue1868] threading.local doesn't free attrs when assigning thread exits

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue1868> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9727] Add callbacks to be invoked when locale changes

New submission from Nick Coghlan : As part of the PEP 384 discussion, it was noted that one of the problems with mixed C runtimes on Windows is that each C runtime in the process has it's own idea of the current locale setting. This can be addressed to some degree by having extension mo

[issue8649] Py_UNICODE_* functions are undocumented

Nick Coghlan added the comment: For this one, I suggest adding something to http://docs.python.org/dev/c-api/unicode.html#plain-py-unicode -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue8

[issue9755] Fix refcounting details in Py3k C API documentation

New submission from Nick Coghlan : As noted in [1] the refcount data for the C API documentation is contained in a separate file at Doc/data/refcounts.dat. This file is not mentioned in "Documenting Python" and hence has not been correctly updated for Py3k (e.g. none of the PyStri

[issue9755] Fix refcounting details in Py3k C API documentation

Changes by Nick Coghlan : -- assignee: -> d...@python nosy: +d...@python ___ Python tracker <http://bugs.python.org/issue9755> ___ ___ Python-bugs-list mai

[issue9789] Explicit buffer release for memoryview objects

New submission from Nick Coghlan : memoryview objects currently offer no way to explicitly release the underlying buffer. This may cause problems for mutable objects that are locked while PEP 3118 buffer references remain unreleased (e.g. in 3.2, io.BytesIO supports getbuffer() for direct

[issue9789] Explicit buffer release for memoryview objects

Nick Coghlan added the comment: The test suite actually does force a GC collection cycle, so the test may be more portable than I first thought, but the need to do that suggests an explicit buffer release API may be a more appropriate solution

[issue9789] Explicit buffer release for memoryview objects

Nick Coghlan added the comment: Thanks for that link. Compared to what either of us managed in the original thread, I think my first post here better articulates why the ability to explicitly release the buffer is important - not because of general memory usage, but because the object owning

[issue9789] Explicit buffer release for memoryview objects

Changes by Nick Coghlan : -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue9789> ___ ___ Python-bugs-list

[issue9789] Explicit buffer release for memoryview objects

Changes by Nick Coghlan : -- superseder: -> Add context manager protocol to memoryviews ___ Python tracker <http://bugs.python.org/issue9789> ___ ___ Python-

[issue9757] Add context manager protocol to memoryviews

Nick Coghlan added the comment: I closed 9789 as a duplicate of this. Bringing the details from that issue over here: memoryview objects currently offer no way to explicitly release the underlying buffer. This may cause problems for mutable objects that

[issue9757] Add context manager protocol to memoryviews

Nick Coghlan added the comment: >> Is this not covered by PEP 3118 at all? > > The PEP says “this memory view object holds on to the memory of base > [i.e. the object the buffer was acquired from] until it is deleted”. > Apparently issues pertaining to delayed garbage

[issue9757] Add context manager protocol to memoryviews

Nick Coghlan added the comment: On an eyeball review, the structure of do_release seems a little questionable to me. I'd be happier if view.obj and view.buf were copied to C locals and then set to NULL at the start of the function before any real work is done. I believe the buffer re

[issue9757] Add context manager protocol to memoryviews

Nick Coghlan added the comment: One other question: should IS_RELEASED use "||" rather than "&&"? Is there any case where either of those pointers can be NULL and we still want to continue on rather than b

[issue9757] Add context manager protocol to memoryviews

Nick Coghlan added the comment: Sounds good - I'd say just commit whenever you're happy with it then. -- ___ Python tracker <http://bugs.python.

[issue9716] The inittab modules cannot be packages

Nick Coghlan added the comment: I assume Brett marked this 3.x only because we currently don't support builtin packages at all, so making this work crosses way over into feature request territory. That makes it unsuitable for a branch in maintenance mode (i.e. 2.7). Added the rel

[issue8077] urlparse

Changes by Nick Coghlan : -- title: cgi handling of POSTed files is broken -> urlparse ___ Python tracker <http://bugs.python.org/issue8077> ___ ___ Python-

[issue9873] Allow bytes in some APIs that use string literals internally

New submission from Nick Coghlan : As per python-dev discussion in June, many Py3k APIs currently gratuitously prevent the use of bytes and bytearray objects as arguments due to their use of string literals internally. Examples: urllib.parse.urlparse urllib.parse.urlunparse

[issue9886] Make operator.itemgetter/attrgetter/methodcaller easier to discover

New submission from Nick Coghlan : The observation has been made that there are some idioms related to key functions passed to various methods and functions that aren't particularly easy to discover. One suggestion is to create a "key function" glossary entry that provid

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: >From the python-dev thread >(http://mail.python.org/pipermail/python-dev/2010-September/103780.html): == So the domain of any polymorphic text manipulation functions we define would be: - Unicode strings - byte sequences where the encod

[issue6627] threading.local() does not work with C-created threads

Nick Coghlan added the comment: Swapnil's analysis looks correct to me - there are certain rules you have to follow before calling back into the Python interpreter core. If you don't follow them, the behaviour you will get is completely undefined. If the problem still occurs even

[issue6627] threading.local() does not work with C-created threads

Nick Coghlan added the comment: The suggestion in http://bugs.python.org/issue6627#msg116722 is a good one. This a case where the user may legitimately not realise that threading.local is stored in the *temporary* state created by ctypes rather than in something more persistent inside the

[issue9360] nntplib cleanup

Nick Coghlan added the comment: To make the distinction easier to remember, would it help if the methods that are currently set to return bytes instead accepted the typical encoding+errors parameters, with parallel *b APIs to get at the raw bytes? My concern with the current API is that

[issue1866] const arg for PyInt_FromString

Nick Coghlan added the comment: I'm rejecting this due to the effect it has on the output parameters. The patch ends up have to stick (char *) casts in several places because a pointer into the string provided via the char * input parameter is returned by each affected API to the ca

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: The design approach (at least for urllib.parse) is to add separate *b APIs that operate on bytes rather than implicitly allowing bytes in the ordinary versions of the function. Allowing programmers to manipulate correctly encoded (and hence ASCII compatible

[issue6627] threading.local() does not work with C-created threads

Nick Coghlan added the comment: On Tue, Sep 21, 2010 at 2:39 PM, Swapnil Talekar wrote: > Swapnil Talekar added the comment: > Nick, the last statement, > "While this is correct for most purposes, it does mean that..." > can be simplified to, > "It means..."

[issue9325] Add an option to pdb/trace/profile to run library module as a script

Nick Coghlan added the comment: I've thought about this in the past, but never really pursued it due to the question of what to do with the __main__ namespace. There are three options here: 1. Use runpy.run_module to run the module in a fresh __main__ namespace 2. Use runpy.run_module t

[issue9790] ntpath contains imports inside functions

Nick Coghlan added the comment: Yeah, I realised shortly after I sent my email in response to the checkin that the original version was covering more cases in that first try-block. I'll defer to you when it comes to exactly which case that NotImplementedError was covering - patch looks

[issue9943] TypeError message became less helpful in Python 2.7

Nick Coghlan added the comment: Having seen the reversion go by on the checkins list, I think there are distinctions the interpreter should be making here in order to improve the error messages, but it isn't. Ideally, we want to be able to tell the user (without writing War and Peace a

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: Attached patch is a very rough first cut at this. I've gone with the basic approach of simply assigning the literals to local variables in each function that uses them. My rationale for that is: 1. Every function has to have some kind of boilerplate to s

[issue9969] tokenize: add support for tokenizing 'str' objects

Nick Coghlan added the comment: Possible approach (untested): def get_tokens(source): if hasattr(source, "encode"): # Already decoded, so bypass encoding detection return _tokenize(io.StringIO(source).readline, None) # Otherwise attempt to detect the correc

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: A possible duck-typing approach here would be to replace the "instance(x, str)" tests with "hasattr(x, 'encode')" checks instead. Thoughts? -- ___ Python tracker <

[issue9969] tokenize: add support for tokenizing 'str' objects

Nick Coghlan added the comment: As per Antoine's comment on #9873, requiring a real string via isinstance(source, str) to trigger the string IO version is likely to be cleaner than attempting to duck-type this. Strings are an area where we make so many assumptions about the way

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: Agreed - I think there's a non-zero chance of triggering the str-path by mistake if we try to duck-type it (I just added a similar comment to #9969 regarding a possible convenience API for tokenis

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: Added to Reitveld: http://codereview.appspot.com/2318041/ -- ___ Python tracker <http://bugs.python.org/issue9873> ___ ___ Pytho

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: One of Antoine's review comments made me realise I hadn't explicitly noted the "why not decode with latin-1?" rationale for the bytes handling. (It did come up in one or more of the myriad python-dev discussions on the topic, I just hadn&#

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: > I think it's quite misguided. latin1 encoding and decoding is blindingly > fast (on the order of 1GB/s. here). Unless you have multi-megabyte URLs, > you won't notice any overhead. Ah, I didn't know that (although it makes sense now

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: >From a function *user* perspective, the latter API (bytes->bytes, str->str) is >exactly what I'm doing. Antoine's point is that there are two ways to achieve that: Option 1 (what my patch currently does): - provide bytes and str var

[issue9873] Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: Yeah, the general implementation concept I'm thinking of going with for option 2 will use a few helper functions: url, coerced_to_str = _coerce_to_str(url) if coerced_to_str: param = _force_to_str(param) # as appropriate ... return _undo_coercion(r

[issue9951] introduce bytes.hex method

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue9951> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9951] introduce bytes.hex method

Nick Coghlan added the comment: Patch generally looks good, but the type of retbuf is incorrect (should be Py_UNICODE* rather than wchar_t*). -- ___ Python tracker <http://bugs.python.org/issue9

[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: As per RDM's email to python-dev, a better way to create the pseudo_str values would be by decoding as ascii with a surrogate escape error handler rather than by decoding as latin-1. -- ___ Python tracker

[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: Yeah, I'll have to time it to see how much difference latin-1 vs surrogateescape makes when the MSB is set in any bytes. -- ___ Python tracker <http://bugs.python.org/i

[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: On Tue, Oct 5, 2010 at 5:32 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > >> If you were worried about performance, then surrogateescape is certainly >> much slower than latin1. > > If you were really worried a

[issue9325] Add an option to pdb/trace/profile to run library module as a script

Nick Coghlan added the comment: On Wed, Oct 6, 2010 at 2:59 AM, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > I am afraid, for ordinary scripts these modules effectively use option 3.  I > think these modules should remove its own scaffol

[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: I've been pondering the idea of adopting a more conservative approach here, since there are actually two issues: 1. Properly quoted URLs are transferred as pure 7-bit ASCII (due to percent-encoding of everything else). However, most of the manipul

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: The difference here is the one pointed out in the original post: for a function, you usually only care about having a value, so if you don't want to call it, you can just swap in a None value instead. If you need an actual callable, then "lambda:None

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: Actually, the singleton idea isn't a bad one, but I'd go one step further and skip the factory function as well. So change that to be: class NullContext(): ... # as per nullcontext in my last message nullcontext = NullContext() (with the exam

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: If you can supply a full patch before the end of the month, we should be able to get this in for 3.2beta1 (currently scheduled for 31 October) -- ___ Python tracker <http://bugs.python.org/issue10

[issue10049] Add a "no-op" (null) context manager to contextlib

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker <http://bugs.python.org/issue10049> ___ ___ Python-bugs-list mailing list Unsubscri

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: To me, this is more a matter of conceptual completeness than one of practical utility (ala fractions.Fraction). That said, I *have* personally encountered the "I only sometimes want to wrap this code in a CM" situation, so it isn't complet

[issue10089] Add support for arbitrary -X options

Nick Coghlan added the comment: I suggest using sys._xoptions to make it clearer that this is for CPython specific internal implementation runtime tweaks. We're putting it in sys so *we* can get at it, not applications. (It also makes it clear that other implementations aren't

[issue5178] Add context manager for temporary directory

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker <http://bugs.python.org/issue5178> ___ ___ Python-bugs-list mailing list Unsubscri

[issue8202] sys.argv[0] and python -m package

Changes by Nick Coghlan : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue8202> ___ ___ Python-bugs-list mailing list Unsubscri

[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown

New submission from Nick Coghlan : During interpreter shutdown, modules can become unusable as module globals are set to None. This is a problem for tempfile.TemporaryDirectory, as it needs working os, os.path and stat modules in order to clean up the filesystem. The class makes a valiant

[issue10188] tempfile.TemporaryDirectory may throw errors at shutdown

Nick Coghlan added the comment: Cleanup of sys and __builtin__ is already delayed - this particular issue could be fixed by delaying cleanup of a few more modules, along with the proposed change to GC invocation in issue #1545463. -- ___ Python

[issue5178] Add context manager for temporary directory

Nick Coghlan added the comment: Committed (with enhanced tests and a few fixes) in r85818 And credit where it's due to test___all__ for picking up a typo in my adjustment to tempfile.__all__ :) I created issue #10188 to track the shutdown problem. I'm considering taking out the

[issue5178] Add context manager for temporary directory

Changes by Nick Coghlan : -- resolution: -> accepted status: open -> closed ___ Python tracker <http://bugs.python.org/issue5178> ___ ___ Python-bugs-list

[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: Attached a second version of the patch. Notable features: - uses a coercion-to-str-and-back strategy (using ascii-strict) - a significantly more comprehensive pass through the urlparse test suite. I'm happy that the test suite mods are complete with this

[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally

Nick Coghlan added the comment: Unless I hear some reasonable objections within the next week or so, I'm going to document and commit the ascii-strict coercion approach for beta 1. The difference in code clarity is such that I'm not even going to try to benchmark the two approach

[issue10049] Add a "no-op" (null) context manager to contextlib

Nick Coghlan added the comment: I find Raymond's perspective persuasive in this case. Feel free to post either the original idea or my later variant as an ASPN cookbook recipe. (you could actually combine the two, and use NullContext as an implementation detail of an optional_cm() fun

[issue2690] Precompute range length

Nick Coghlan added the comment: I'd still like to have another look at this before beta 1, but can't promise I'll get to it. Unassigning in case someone else has some roundtuits to spare over the next few weeks. -- ass

[issue5251] contextlib.nested inconsistent with, well, nested with statements due exceptions raised in __enter__

Nick Coghlan added the comment: R.I.P contextlib.nested (it is gone in 3.2 following the deprecation in 3.1). The issue is obscure enough that I don't see much value in updating the documentation for the versions that still contain it in deprecated form. -- resolution: ->

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Nick Coghlan added the comment: I still think this is a good idea, I'm just not actively working on it. It might make a good project for someone wanting to get to know the process of working on CPython without having to deal with anything that is particularly tricky to under

[issue5178] Add context manager for temporary directory

Nick Coghlan added the comment: Merging the interfaces for mkdtemp and TemporaryDirectory isn't going to happen. mkstemp/mkdtemp are for when the user wants to control the lifecycle of the filesystem entries themselves. (Note that context management on a regular file-like object only c

[issue2001] Pydoc interactive browsing enhancement

Nick Coghlan added the comment: Unassigning from ping given the lack of comments - I should be able to have a look at this in time for beta 1 -- assignee: ping -> ncoghlan ___ Python tracker <http://bugs.python.org/iss

[issue10220] Make generator state easier to introspect

New submission from Nick Coghlan : Generators can be in four different states that may be relevant to framework code making use of them (especially as coroutines). This state is all currently available from Python code, but is rather obscure and could be made readable. The four states are

[issue10220] Make generator state easier to introspect

Nick Coghlan added the comment: On Thu, Oct 28, 2010 at 10:55 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Is it CPython-specific? The states are not CPython-specific (they're logical states of the underlying generator), but I don't know if other

[issue10220] Make generator state easier to introspect

Nick Coghlan added the comment: So something like: GEN_CREATED, GEN_ACTIVE, GEN_CLOSED = range(3) def getgeneratorstate(g): """Get current state of a generator-iterator. Possible states are: GEN_CREATED: Created, waiting to start execution GEN_ACTIVE: Currently

[issue10220] Make generator state easier to introspect

Nick Coghlan added the comment: Indeed, the minimal lifecycles are: GEN_CREATED->GEN_CLOSED (exception thrown in before the generator was even started) GEN_CREATED->GEN_RUNNING->GEN_CLOSED (initial next() with internal logic that skips all yields) GEN_CREATED->GEN_RUNNING-&g

[issue10220] Make generator state easier to introspect

Changes by Nick Coghlan : -- assignee: -> ncoghlan ___ Python tracker <http://bugs.python.org/issue10220> ___ ___ Python-bugs-list mailing list Unsubscri

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: Since it works for me (I tried both r84120, my old 2.7 build from August or so, and r86033, which is the 2.7 head), we'll need more information. The starting blurb from the interactive prompt would be a good place to start. (-m was slightly broken from

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: Note also that site.py runs twice when used with -m: once implicitly during interpreter startup, and a second time as the main module. Due to the way the interpreter starts up and figures out sys.path, it is possible for the implicit import to pick up the

[issue10263] "python -m site" does not print path details

Changes by Nick Coghlan : -- nosy: +ronaldoussoren ___ Python tracker <http://bugs.python.org/issue10263> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: r82508 is the correct release binary (created after the error I mentioned above was fixed). I've CC'ed Ronald to see if he can shed any light - it may be a platform specific issue with the way sys.path is

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: No, there won't be another binary release until 2.7.1 comes out. The SVN revision number ratchets up pretty fast, since it is counting checkins on *all* branches, even experimental ones. -- ___ Python tracker

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: Yeah, because the internal import system isn't fully exposed, runpy and a couple of other tools in the standard library rely on the emulation in pkgutil instead. I know there are some differences between the emulation and the builtin mechanism on Windo

<    1   2   3   4   5   6   7   8   9   10   >