Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On 15 April 2012 18:13, Raymond Hettinger wrote: > We should publish some advice on creating content managers. > > Context managers are a general purpose tool but have a primary > use case of creating and releasing resources. This creates an > expectation that that is what the context managers are doing unless > they explicitly say otherwise. I'd have said this was unnecessary, but the sqlite example shows it isn't, so +1 from me. As a database specialist, the sqlite behaviour you show is completely non-intuitive :-( Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10576: Add a progress callback to gcmodule
On 15.04.2012 13:42, kristjan.jonsson wrote: http://hg.python.org/cpython/rev/88f8ef5785d7 changeset: 76319:88f8ef5785d7 user:Kristján Valur Jónsson date:Sun Apr 15 11:41:32 2012 + summary: Issue #10576: Add a progress callback to gcmodule files: Doc/library/gc.rst | 39 - Lib/test/test_gc.py | 136 +++- Misc/NEWS |3 + Modules/gcmodule.c | 80 +- 4 files changed, 249 insertions(+), 9 deletions(-) diff --git a/Doc/library/gc.rst b/Doc/library/gc.rst --- a/Doc/library/gc.rst +++ b/Doc/library/gc.rst @@ -153,8 +153,8 @@ .. versionadded:: 3.1 -The following variable is provided for read-only access (you can mutate its -value but should not rebind it): +The following variables are provided for read-only access (you can mutate the +values but should not rebind them): .. data:: garbage @@ -183,6 +183,41 @@ :const:`DEBUG_UNCOLLECTABLE` is set, in addition all uncollectable objects are printed. +.. data:: callbacks + + A list of callbacks that will be invoked by the garbage collector before and + after collection. The callbacks will be called with two arguments, + :arg:`phase` and :arg:`info`. + + :arg:`phase` can one of two values: There is no role ":arg:". Please fix it to *phase* etc. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
Brett Cannon, 14.04.2012 20:12: > My multi-year project -- started in 2006 according to my blog -- to rewrite > import in pure Python and then bootstrap it into CPython as *the* > implementation of __import__() is finally over (mostly)! Hopefully I didn't > break too much code in the process. =) Well, some at least. The new import cache broke Cython's load of on-the-fly compiled extension modules, which naively used "__import__(module_name)" after building them. I could fix that by moving to "imp.load_dynamic()" (we know where we put the compiled module anyway), although I just noticed that that's not actually documented. So I hope that won't break later on. The next thing I noticed is that the old-style level -1 import no longer works, which presumably breaks a *lot* of Cython compiled modules. It used to work in the master branch until two days ago, now it raises a ValueError. We may be able to fix this by copying over CPython's old import code into Cython, but I actually wonder if this was really intended. If this feature wasn't deliberately broken in Py3.0, why break it now? Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Providing a mechanism for PEP 3115 compliant dynamic class creation
On Mon, Apr 16, 2012 at 04:17, Nick Coghlan wrote: > Sure, just create a new tracker issue and assign it to me. You already > know better than most what the _prepare() step needs to do :) I've created http://bugs.python.org/issue14588, and attached the first version of a patch. I can't assign it to you, but you're on the nosy list. Thanks, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
This is becoming the Manhattan Project of bike sheds. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
2012/4/16 Matt Joiner : > This is becoming the Manhattan Project of bike sheds. FreeBSD FAQ contains an entry "Why should I care what color the bikeshed is?" which mention a "sleep(1) should take fractional second arguments" saga in 1999. http://www.freebsd.org/doc/en/books/faq/misc.html#BIKESHED-PAINTING Bikeshedding is maybe a common issue with the discussion around time function? :-) Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
On Mon, Apr 16, 2012 at 12:38:41PM +0200, Victor Stinner wrote: > Bikeshedding is maybe a common issue with the discussion around time > function? :-) Perhaps because everyone of us lives in a different Time-Space Continuum? ;-) Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, 16 Apr 2012 09:54:41 +0200 Stefan Behnel wrote: > > The new import cache broke Cython's load of on-the-fly compiled extension > modules, which naively used "__import__(module_name)" after building them. > I could fix that by moving to "imp.load_dynamic()" (we know where we put > the compiled module anyway), although I just noticed that that's not > actually documented. So I hope that won't break later on. You can call importlib.invalidate_caches(). http://docs.python.org/dev/library/importlib.html#importlib.invalidate_caches > The next thing I noticed is that the old-style level -1 import no longer > works, which presumably breaks a *lot* of Cython compiled modules. It used > to work in the master branch until two days ago, now it raises a > ValueError. We may be able to fix this by copying over CPython's old import > code into Cython, but I actually wonder if this was really intended. If > this feature wasn't deliberately broken in Py3.0, why break it now? Regressions should be reported on the bug tracker IMHO. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
On Mon, 16 Apr 2012 01:25:42 +0200 Victor Stinner wrote: > > I suppose that most people don't care that "resolution" and > "precision" are different things. Don't they? Actually, they don't care about resolution since they receive a Python float. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #10854. Make use of the new path and name attributes on ImportError
On Mon, 16 Apr 2012 07:10:31 +0200 brian.curtin wrote: > PyErr_SetFromImportErrorWithNameAndPath Apparently this new function isn't documented anywhere. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
Antoine Pitrou, 16.04.2012 13:13: > On Mon, 16 Apr 2012 09:54:41 +0200 > Stefan Behnel wrote: >> >> The new import cache broke Cython's load of on-the-fly compiled extension >> modules, which naively used "__import__(module_name)" after building them. >> I could fix that by moving to "imp.load_dynamic()" (we know where we put >> the compiled module anyway), although I just noticed that that's not >> actually documented. So I hope that won't break later on. > > You can call importlib.invalidate_caches(). > http://docs.python.org/dev/library/importlib.html#importlib.invalidate_caches Well, yes, but imp.load_dynamic() would be the right thing to do for us. Is there a reason why it's not documented? I would like to avoid changing the code to load_dynamic() now and then having to realise that that's going to die in 3.3 final because it somehow got in the way of the importlob rewrites and is not being considered a valuable enough public API. New doc bug ticket: http://bugs.python.org/issue14594 >> The next thing I noticed is that the old-style level -1 import no longer >> works, which presumably breaks a *lot* of Cython compiled modules. It used >> to work in the master branch until two days ago, now it raises a >> ValueError. We may be able to fix this by copying over CPython's old import >> code into Cython, but I actually wonder if this was really intended. If >> this feature wasn't deliberately broken in Py3.0, why break it now? > > Regressions should be reported on the bug tracker IMHO. It was meant as more of a question for now, but here it goes: http://bugs.python.org/issue14592 Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
> We have other instances of this (e.g. the Objects/typeslots.inc file > is generated and checked in), but in the case of importlib, we have > to use the ./python binary for freezing to avoid bytecode > incompatibilities, which obviously is a problem if ./python isn't > built yet. As for dependencies on byte code: we could consider using Cython instead of freeze (not sure whether Cython would build the bootstrap correctly; it may need to be fixed first). With that, we would get semi-readable source code, which should also play more nicely with hg diffs. On the down side, we would depend on Cython for evolving . As for the timestamp issue: I think we should add a target "make touch" or some such which checks whether the respective files are unmodified in the local clone, and if so, arranges to touch generated files that are older than their sources. If this is done by a plain shell script, one could also make this a post-update Mercurial hook. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #10854. Make use of the new path and name attributes on ImportError
On Mon, Apr 16, 2012 at 07:19, Antoine Pitrou wrote: > On Mon, 16 Apr 2012 07:10:31 +0200 > brian.curtin wrote: > > PyErr_SetFromImportErrorWithNameAndPath > > Apparently this new function isn't documented anywhere. > > I forgot to write the docs for it when I committed Brian's code. Brian, do you mind writing the docs for the two functions? -Brett > Regards > > Antoine. > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #10854. Make use of the new path and name attributes on ImportError
On Mon, Apr 16, 2012 at 09:52, Brett Cannon wrote: > > > On Mon, Apr 16, 2012 at 07:19, Antoine Pitrou wrote: >> >> On Mon, 16 Apr 2012 07:10:31 +0200 >> brian.curtin wrote: >> > PyErr_SetFromImportErrorWithNameAndPath >> >> Apparently this new function isn't documented anywhere. >> > > I forgot to write the docs for it when I committed Brian's code. > > Brian, do you mind writing the docs for the two functions? I'll take care of it today. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, Apr 16, 2012 at 10:07, "Martin v. Löwis" wrote: > > We have other instances of this (e.g. the Objects/typeslots.inc file > > is generated and checked in), but in the case of importlib, we have > > to use the ./python binary for freezing to avoid bytecode > > incompatibilities, which obviously is a problem if ./python isn't > > built yet. > > As for dependencies on byte code: we could consider using Cython instead > of freeze (not sure whether Cython would build the bootstrap correctly; > it may need to be fixed first). With that, we would get semi-readable > source code, which should also play more nicely with hg diffs. On the > down side, we would depend on Cython for evolving . > We could also just store the raw source code and use that if we are all willing to pay the performance cost of parsing and compiling the code at every startup. > > As for the timestamp issue: I think we should add a target "make touch" > or some such which checks whether the respective files are unmodified > in the local clone, and if so, arranges to touch generated files that > are older than their sources. If this is done by a plain shell script, > one could also make this a post-update Mercurial hook. > So like execute hg diff on the dependent files and if nothing changed then touch the auto-generated file w/ 'touch' to prevent future attempts to execute the target? -Brett > > Regards, > Martin > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On Apr 15, 2012, at 01:13 PM, Raymond Hettinger wrote: >We should publish some advice on creating content managers. I agree, I'm just not sure PEP 8 is the right place for it. PEP 8 seems like it is structured more as mechanical guidelines for the look and feel of code, not so much for the semantic content of the code. As such, including best practices for naming context managers would both appear out-of-place, and possibly get lost in all the whitespace noise :). Perhaps the contextlib docs are a better place for this? -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, 16 Apr 2012 11:21:34 -0400, Brett Cannon wrote: > On Mon, Apr 16, 2012 at 10:07, "Martin v. Löwis" wrote: > > > > We have other instances of this (e.g. the Objects/typeslots.inc file > > > is generated and checked in), but in the case of importlib, we have > > > to use the ./python binary for freezing to avoid bytecode > > > incompatibilities, which obviously is a problem if ./python isn't > > > built yet. > > > > As for dependencies on byte code: we could consider using Cython instead > > of freeze (not sure whether Cython would build the bootstrap correctly; > > it may need to be fixed first). With that, we would get semi-readable > > source code, which should also play more nicely with hg diffs. On the > > down side, we would depend on Cython for evolving . > > > > We could also just store the raw source code and use that if we are all > willing to pay the performance cost of parsing and compiling the code at > every startup. I don't see how depending on Cython is better than depending on having an existing Python. If the only benefit is semi-readable code, surely we do have source code for the pre-frozen module, and it is just a matter of convincing hg that the bytecode is binary, not text? Brett's earlier thought of compiling from source as a *fallback* makes sense to me. I'd rather not add overhead to startup that we can avoid. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, 16 Apr 2012 12:15:16 -0400 "R. David Murray" wrote: > > I don't see how depending on Cython is better than depending on having > an existing Python. If the only benefit is semi-readable code, surely > we do have source code for the pre-frozen module, and it is just a matter > of convincing hg that the bytecode is binary, not text? > > Brett's earlier thought of compiling from source as a *fallback* makes > sense to me. I'd rather not add overhead to startup that we can avoid. Compiling from source at which point, though? In essence, that would mean reimplement Python/freeze_importlib.py in C? We could even compile it to a separate executable that gets built before the Python executable (like pgen) :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, Apr 16, 2012 at 12:31, Antoine Pitrou wrote: > On Mon, 16 Apr 2012 12:15:16 -0400 > "R. David Murray" wrote: > > > > I don't see how depending on Cython is better than depending on having > > an existing Python. If the only benefit is semi-readable code, surely > > we do have source code for the pre-frozen module, and it is just a matter > > of convincing hg that the bytecode is binary, not text? > > > > Brett's earlier thought of compiling from source as a *fallback* makes > > sense to me. I'd rather not add overhead to startup that we can avoid. > > In reply to David, one trick with this, though, is that frozen modules don't store the magic number of the bytecode, so that would need to change in order to make this fully feasible. > Compiling from source at which point, though? > At startup of the interpreter. > In essence, that would mean reimplement Python/freeze_importlib.py in C? > We could even compile it to a separate executable that gets built > before the Python executable (like pgen) :-) > So a mini Python that just knew how to compile to bytecode and nothing more? -Brett > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
> I don't see how depending on Cython is better than depending on having > an existing Python. If the only benefit is semi-readable code, surely > we do have source code for the pre-frozen module, and it is just a matter > of convincing hg that the bytecode is binary, not text? Cython-generated C code would likely be more stable (and produce compiler errors if it gets stale), whereas importlib.h needs to be regenerated with byte code changes. Having source code has the advantage that it becomes possible to single-step through the import process in C debugger. Single-stepping with pdb would, of course, be better than that, but I doubt it's feasible. In addition, there might be a performance gain with Cython over ceval. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
> So like execute hg diff on the dependent files and if nothing changed > then touch the auto-generated file w/ 'touch' to prevent future attempts > to execute the target? Exactly. There might be something better than hg diff, perhaps some form of hg status. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, Apr 16, 2012 at 13:04, "Martin v. Löwis" wrote: > > I don't see how depending on Cython is better than depending on having > > an existing Python. If the only benefit is semi-readable code, surely > > we do have source code for the pre-frozen module, and it is just a matter > > of convincing hg that the bytecode is binary, not text? > > Cython-generated C code would likely be more stable (and produce > compiler errors if it gets stale), whereas importlib.h needs to be > regenerated with byte code changes. > > Having source code has the advantage that it becomes possible to > single-step through the import process in C debugger. Single-stepping > with pdb would, of course, be better than that, but I doubt it's > feasible. > > In addition, there might be a performance gain with Cython over ceval. > The other benefit is maintainability. In order to hit my roughly 5% startup speed I had to rewrite chunks of __import__() in C code and then delegate to importlib's Python code in cases where sys.modules was not hit. Using Cython would mean that can all go away and the differences between the C and Python code would become (supposedly) non-existent, making tweaks easier (e.g. when I made the change to hit sys.modules less when a loader returned the desired module it was annoying to have to change importlib *and* import.c). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, Apr 16, 2012 at 13:08, "Martin v. Löwis" wrote: > > So like execute hg diff on the dependent files and if nothing changed > > then touch the auto-generated file w/ 'touch' to prevent future attempts > > to execute the target? > > Exactly. There might be something better than hg diff, perhaps some form > of hg status. > Yeah, hg status is probably better. Now someone just needs to write the shell script. =) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, Apr 16, 2012 at 11:32 AM, Brett Cannon wrote: > > > On Mon, Apr 16, 2012 at 13:04, "Martin v. Löwis" wrote: >> >> > I don't see how depending on Cython is better than depending on having >> > an existing Python. If the only benefit is semi-readable code, surely >> > we do have source code for the pre-frozen module, and it is just a >> > matter >> > of convincing hg that the bytecode is binary, not text? >> >> Cython-generated C code would likely be more stable (and produce >> compiler errors if it gets stale), whereas importlib.h needs to be >> regenerated with byte code changes. >> >> Having source code has the advantage that it becomes possible to >> single-step through the import process in C debugger. Single-stepping >> with pdb would, of course, be better than that, but I doubt it's >> feasible. >> >> In addition, there might be a performance gain with Cython over ceval. > > > The other benefit is maintainability. In order to hit my roughly 5% startup > speed I had to rewrite chunks of __import__() in C code and then delegate to > importlib's Python code in cases where sys.modules was not hit. Using Cython > would mean that can all go away and the differences between the C and Python > code would become (supposedly) non-existent, making tweaks easier (e.g. when > I made the change to hit sys.modules less when a loader returned the desired > module it was annoying to have to change importlib *and* import.c). +1 on reducing the complexity of the import code. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, 16 Apr 2012 13:33:45 -0400 Brett Cannon wrote: > On Mon, Apr 16, 2012 at 13:08, "Martin v. Löwis" wrote: > > > > So like execute hg diff on the dependent files and if nothing changed > > > then touch the auto-generated file w/ 'touch' to prevent future attempts > > > to execute the target? > > > > Exactly. There might be something better than hg diff, perhaps some form > > of hg status. > > > > Yeah, hg status is probably better. Now someone just needs to write the > shell script. =) Wouldn't it be better if Python could compile regardless of the presence of a hg repository? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Apr 16, 2012, at 07:44 PM, Antoine Pitrou wrote: >Wouldn't it be better if Python could compile regardless of the >presence of a hg repository? If you want it in your $DISTRO, yes please! -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, 16 Apr 2012 13:51:35 -0400, Barry Warsaw wrote: > On Apr 16, 2012, at 07:44 PM, Antoine Pitrou wrote: > > >Wouldn't it be better if Python could compile regardless of the > >presence of a hg repository? > > If you want it in your $DISTRO, yes please! My impression is that our usual solution for this is to make sure the timestamps are correct in distributed tarballs, so that the hg-dependent machinery is not invoked when building from a release tarball. Is this case any different? --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
"Martin v. Löwis", 16.04.2012 16:07: >> We have other instances of this (e.g. the Objects/typeslots.inc file >> is generated and checked in), but in the case of importlib, we have >> to use the ./python binary for freezing to avoid bytecode >> incompatibilities, which obviously is a problem if ./python isn't >> built yet. > > As for dependencies on byte code: we could consider using Cython instead > of freeze (not sure whether Cython would build the bootstrap correctly; > it may need to be fixed first). I assume that this would be needed rather early during the interpreter startup, so you're right that there may be obstacles due to expectations in the generated C code that may not be there yet. But I think it's worth a try. Cython is rather predictable in its requirements given the Python source code. Just run the module through Cython and see what it gives you. (Note that you may need the latest github master version to make everything work nicely in Py3.3, I keep adapting things there as I find them - our CI server runs daily tests against the latest CPython master.) One thing Cython does during module initialisation is to import the builtins module using PyModule_AddModule(). Does that work already at this point? It uses it mostly to cache builtins that the module uses. That can be disabled, though, and I also wouldn't mind letting Cython put a preprocessor guard into that code that would let it do something else based on a macro that CPython defines at this point, maybe even just Py_BUILD_CORE. We already do these things for all sorts of purposes. And, obviously, the module init function can also be called directly instead of running it as part of an import. That's commonly done when using Cython modules in an embedded Python runtime. > With that, we would get semi-readable > source code, which should also play more nicely with hg diffs. There's still a Cython patch hanging around on github that aims to keep the C code from changing all that drastically on Python source code changes (e.g. due to source line references etc.). Might be worth integrating for something like this. There's also a switch that disables the (helpful) reproduction of the Python code context in C code comments, in case that gets in the way for diffs. > On the down side, we would depend on Cython for evolving . Right, although not as a strict dependency. The code would still work just fine in plain Python. But it would depend on Cython for performance. And we usually recommend to ship the generated C sources anyway to avoid a user dependency on Cython, so this use case is quite normal. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #10854. Make use of the new path and name attributes on ImportError
On Mon, Apr 16, 2012 at 09:54, Brian Curtin wrote: > On Mon, Apr 16, 2012 at 09:52, Brett Cannon wrote: >> >> >> On Mon, Apr 16, 2012 at 07:19, Antoine Pitrou wrote: >>> >>> On Mon, 16 Apr 2012 07:10:31 +0200 >>> brian.curtin wrote: >>> > PyErr_SetFromImportErrorWithNameAndPath >>> >>> Apparently this new function isn't documented anywhere. >>> >> >> I forgot to write the docs for it when I committed Brian's code. >> >> Brian, do you mind writing the docs for the two functions? > > I'll take care of it today. Done. http://hg.python.org/cpython/rev/5cc8b717b38c ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Fix #10854. Make use of the new path and name attributes on ImportError
Le lundi 16 avril 2012 à 15:27 -0500, Brian Curtin a écrit : > On Mon, Apr 16, 2012 at 09:54, Brian Curtin wrote: > > On Mon, Apr 16, 2012 at 09:52, Brett Cannon wrote: > >> > >> > >> On Mon, Apr 16, 2012 at 07:19, Antoine Pitrou wrote: > >>> > >>> On Mon, 16 Apr 2012 07:10:31 +0200 > >>> brian.curtin wrote: > >>> > PyErr_SetFromImportErrorWithNameAndPath > >>> > >>> Apparently this new function isn't documented anywhere. > >>> > >> > >> I forgot to write the docs for it when I committed Brian's code. > >> > >> Brian, do you mind writing the docs for the two functions? > > > > I'll take care of it today. > > Done. http://hg.python.org/cpython/rev/5cc8b717b38c It would be nice if the refleak behaviour of these functions was documented too (or, better, fixed, if I'm reading the code correctly; reference-stealing functions are generally a nuisance). By the way, why is the naming so complicated? PyErr_SetImportError() would have sounded explicit enough :) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
Hi, 2012/4/16 Stefan Behnel > > On the down side, we would depend on Cython for evolving . > > Right, although not as a strict dependency. The code would still work just > fine in plain Python. Not quite, we are talking of the imp module here... -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
Am 16.04.2012 19:44, schrieb Antoine Pitrou: > On Mon, 16 Apr 2012 13:33:45 -0400 > Brett Cannon wrote: >> On Mon, Apr 16, 2012 at 13:08, "Martin v. Löwis" wrote: >> So like execute hg diff on the dependent files and if nothing changed then touch the auto-generated file w/ 'touch' to prevent future attempts to execute the target? >>> >>> Exactly. There might be something better than hg diff, perhaps some form >>> of hg status. >>> >> >> Yeah, hg status is probably better. Now someone just needs to write the >> shell script. =) > > Wouldn't it be better if Python could compile regardless of the > presence of a hg repository? Who says it couldn't? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Add documentation for the new PyErr_SetFromImport* functions
On 16.04.2012 22:14, brian.curtin wrote: http://hg.python.org/cpython/rev/5cc8b717b38c changeset: 76363:5cc8b717b38c user:Brian Curtin date:Mon Apr 16 15:14:36 2012 -0500 summary: Add documentation for the new PyErr_SetFromImport* functions files: Doc/c-api/exceptions.rst | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/Doc/c-api/exceptions.rst b/Doc/c-api/exceptions.rst --- a/Doc/c-api/exceptions.rst +++ b/Doc/c-api/exceptions.rst @@ -229,6 +229,24 @@ Similar to :c:func:`PyErr_SetFromWindowsErrWithFilename`, with an additional parameter specifying the exception type to be raised. Availability: Windows. +.. c:function:: PyObject* PyErr_SetExcWithArgsKwargs(PyObject *exc, PyObject *args, PyObject *kwargs) + + This is a convenience function to set an *exc* with the given *args* and + *kwargs* values. If *args* is ``NULL``, an empty :func:`tuple` will be + created when *exc* is created via :c:func:`PyObject_Call`. + +.. c:function:: PyObject* PyErr_SetFromImportErrorWithName(PyObject *msg, PyObject *name) + + This is a convenience function to raise :exc:`ImportError`. *msg* will be + set as the exception's message string, and *name* will be set as the + :exc:`ImportError`'s ``name`` attribute. + +.. c:function:: PyObject* PyErr_SetFromImportErrorWithNameAndPath(PyObject *msg, PyObject *name, PyObject *path) + + This is a convenience function to raise :exc:`ImportError`. *msg* will be + set as the exception's message string. Both *name* and *path* will be set + as the :exc:`ImportError`'s respective ``name`` and ``path`` attributes. + versionadded please. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On 16.04.2012 18:15, R. David Murray wrote: On Mon, 16 Apr 2012 11:21:34 -0400, Brett Cannon wrote: On Mon, Apr 16, 2012 at 10:07, "Martin v. Löwis" wrote: > > We have other instances of this (e.g. the Objects/typeslots.inc file > > is generated and checked in), but in the case of importlib, we have > > to use the ./python binary for freezing to avoid bytecode > > incompatibilities, which obviously is a problem if ./python isn't > > built yet. > > As for dependencies on byte code: we could consider using Cython instead > of freeze (not sure whether Cython would build the bootstrap correctly; > it may need to be fixed first). With that, we would get semi-readable > source code, which should also play more nicely with hg diffs. On the > down side, we would depend on Cython for evolving . That is an interesting idea. We already depend on external tools, e.g. autotools, for updating checked-in files, so why not Cython. We could also just store the raw source code and use that if we are all willing to pay the performance cost of parsing and compiling the code at every startup. I don't see how depending on Cython is better than depending on having an existing Python. No, it's not just an existing Python, it is (at least currently) the same version of Python being built. Therefore I wrote about the bootstrapping problems when bytecode changes. Depending on Cython is better in that it breaks the bootstrapping cycle, but on the other hand the C code may need to be regenerated when the C API changes in an incompatible way. If the only benefit is semi-readable code, surely we do have source code for the pre-frozen module, and it is just a matter of convincing hg that the bytecode is binary, not text? The benefit is also (presumably) better performance. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Add documentation for the new PyErr_SetFromImport* functions
On Mon, Apr 16, 2012 at 18:02, Georg Brandl wrote: > On 16.04.2012 22:14, brian.curtin wrote: >> >> http://hg.python.org/cpython/rev/5cc8b717b38c >> changeset: 76363:5cc8b717b38c >> user: Brian Curtin >> date: Mon Apr 16 15:14:36 2012 -0500 >> summary: >> Add documentation for the new PyErr_SetFromImport* functions >> >> files: >> Doc/c-api/exceptions.rst | 18 ++ >> 1 files changed, 18 insertions(+), 0 deletions(-) >> >> >> diff --git a/Doc/c-api/exceptions.rst b/Doc/c-api/exceptions.rst >> --- a/Doc/c-api/exceptions.rst >> +++ b/Doc/c-api/exceptions.rst >> @@ -229,6 +229,24 @@ >> Similar to :c:func:`PyErr_SetFromWindowsErrWithFilename`, with an >> additional >> parameter specifying the exception type to be raised. Availability: >> Windows. >> >> +.. c:function:: PyObject* PyErr_SetExcWithArgsKwargs(PyObject *exc, >> PyObject *args, PyObject *kwargs) >> + >> + This is a convenience function to set an *exc* with the given *args* >> and >> + *kwargs* values. If *args* is ``NULL``, an empty :func:`tuple` will be >> + created when *exc* is created via :c:func:`PyObject_Call`. >> + >> +.. c:function:: PyObject* PyErr_SetFromImportErrorWithName(PyObject *msg, >> PyObject *name) >> + >> + This is a convenience function to raise :exc:`ImportError`. *msg* will >> be >> + set as the exception's message string, and *name* will be set as the >> + :exc:`ImportError`'s ``name`` attribute. >> + >> +.. c:function:: PyObject* >> PyErr_SetFromImportErrorWithNameAndPath(PyObject *msg, PyObject *name, >> PyObject *path) >> + >> + This is a convenience function to raise :exc:`ImportError`. *msg* will >> be >> + set as the exception's message string. Both *name* and *path* will be >> set >> + as the :exc:`ImportError`'s respective ``name`` and ``path`` >> attributes. >> + > > > versionadded please. http://hg.python.org/cpython/rev/d79aa61ec96d ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
> Here is a simplified version of the first draft of the PEP 418. The > full version can be read online. > http://www.python.org/dev/peps/pep-0418/ I wrote an implementation in pure Python using ctypes for Python < 3.3: https://bitbucket.org/haypo/misc/src/tip/python/pep418.py I tested it on Linux, OpenBSD, FreeBSD and Windows. It's more a proof-of-concept to test the PEP than a library written to be reused by programs. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Tue, 17 Apr 2012 01:11:14 +0200 Georg Brandl wrote: > > No, it's not just an existing Python, it is (at least currently) the same > version of Python being built. Therefore I wrote about the bootstrapping > problems when bytecode changes. > > Depending on Cython is better in that it breaks the bootstrapping cycle, > but on the other hand the C code may need to be regenerated when the C API > changes in an incompatible way. Cython OTOH probably needs Python 2.x, which isn't that great for building Python 3. And requiring Cython for developing is not very contributor-friendly. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 6360B1C859 for ; Tue, 17 Apr 2012 02:48:56 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3VWns40yxrzMjw for ; Tue, 17 Apr 2012 02:48:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1334623736; bh=XEXCeYE16fzcKUQhGMmVsnWAtZLmGW9LmP+Uwy05Fbg=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=czgqyVC9I6R+u4WpYYlnB9GgLDMku29p5VPNX00bYV0sMCCNTpAH4gTB2TF4UJmAZ o1mZSxW7o1qAx1HIa1OOfDsuETDkfVIUznnllKr78KWQsMP+oNX5thjyQCU9QHlCEk bji6LUyqKCut4Bi9fcC6xUg9bG0GuBoeYOZ9KWp0= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 17 Apr 2012 02:48:56 +0200 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Tue, 17 Apr 2012 02:48:56 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1SJwbH-0001PR-UV for rep...@bugs.python.org; Tue, 17 Apr 2012 02:48:55 +0200 Date: Tue, 17 Apr 2012 02:48:55 +0200 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue13959] TmV3IGNoYW5nZXNldCBhODg5NTExN2EzOGQgYnkgQnJldHQgQ2Fubm9uIGluIGJyYW5jaCAnZGVm YXVsdCc6Cklzc3VlICMxMzk1OTogRml4IGEgbG9naWMgYnVnLgpodHRwOi8vaGcucHl0aG9uLm9y Zy9jcHl0aG9uL3Jldi9hODg5NTExN2EzOGQK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou wrote: > On Tue, 17 Apr 2012 01:11:14 +0200 > Georg Brandl wrote: > > > > No, it's not just an existing Python, it is (at least currently) the same > > version of Python being built. Therefore I wrote about the bootstrapping > > problems when bytecode changes. > > > > Depending on Cython is better in that it breaks the bootstrapping cycle, > > but on the other hand the C code may need to be regenerated when the C > API > > changes in an incompatible way. > > Cython OTOH probably needs Python 2.x, which isn't that great for > building Python 3. And requiring Cython for developing is not very > contributor-friendly. > Well, required to regenerate _frozen_importlib, but nothing else. I mean making fixes go into importlib directly and get tested that way, not through __import__(). So really Cython would only be needed when importlib._bootstrap has been changed and you are making a commit. -Brett > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: Add monotonic time, performance counter and process time functions
On 16Apr2012 01:25, Victor Stinner wrote: | I suppose that most people don't care that "resolution" and | "precision" are different things. If we're using the same definitions we discussed offline, where - resolution is the units the clock call (underneath) works in (for example, nanoseconds) - precision is the effective precision of the results, for example milliseconds I'd say people would care if they knew, and mostly care about "precision". -- Cameron Simpson DoD#743 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
Amaury Forgeot d'Arc, 16.04.2012 22:43: > 2012/4/16 Stefan Behnel >>> On the down side, we would depend on Cython for evolving . >> >> Right, although not as a strict dependency. The code would still work just >> fine in plain Python. > > Not quite, we are talking of the imp module here... Hmm, right, after writing the above, I figured that it would at least have to do something like "import sys" in order to deal with the import config (path, meta path, ...). That obviously won't work in pure Python at this point. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
Antoine Pitrou, 17.04.2012 02:27: > On Tue, 17 Apr 2012 01:11:14 +0200 > Georg Brandl wrote: >> No, it's not just an existing Python, it is (at least currently) the same >> version of Python being built. Therefore I wrote about the bootstrapping >> problems when bytecode changes. >> >> Depending on Cython is better in that it breaks the bootstrapping cycle, >> but on the other hand the C code may need to be regenerated when the C API >> changes in an incompatible way. > > Cython OTOH probably needs Python 2.x, which isn't that great for > building Python 3. It uses 2to3 at install time, so you get a Py3 version out of it. No need to have Py2 installed in order to use it. > And requiring Cython for developing is not very > contributor-friendly. Brett Cannon answered that one. If you ship the C sources, developers will only be impacted when they want to modify source code that gets compiled with Cython. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested addition to PEP 8 for context managers
On Mon, Apr 16, 2012 at 8:30 AM, Barry Warsaw wrote: > On Apr 15, 2012, at 01:13 PM, Raymond Hettinger wrote: > >>We should publish some advice on creating content managers. > > I agree, I'm just not sure PEP 8 is the right place for it. > > PEP 8 seems like it is structured more as mechanical guidelines for the look > and feel of code, not so much for the semantic content of the code. As such, I'd like to piggyback this thread for a situtation to consider in PEP 8. PEP 8 suggests no extra spaces after and before square brackets, and colons. So code like this is appropriate: a_list[1:3] But I find it less readable in the case of: a_list[pos + 1:-1] The colon is seemingly lost in the right. Would it be better to read like below? a_list[pos + 1 : -1] Any opinion? Nam ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
