Re: [Python-Dev] Restricted API versioning
> This strikes me as in opposition to the Python-level policy of duck > typing. Would it be more appropriate to, instead of asking if it's > Python 3.3.0, ask if it's a Python that supports PY_FEATURE_FOOBAR? Or > would that result in an unnecessary proliferation of flag macros? It would, hence I'm -1. I believe it is the motivation for the gcc assertion preprocessor feature, which never caught on. 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] Restricted API versioning
On Sun, Jun 24, 2012 at 5:00 PM, "Martin v. Löwis" wrote: >> This strikes me as in opposition to the Python-level policy of duck >> typing. Would it be more appropriate to, instead of asking if it's >> Python 3.3.0, ask if it's a Python that supports PY_FEATURE_FOOBAR? Or >> would that result in an unnecessary proliferation of flag macros? > > It would, hence I'm -1. I believe it is the motivation for the gcc > assertion preprocessor feature, which never caught on. Right, if someone wants to check for a specific feature rather than just figuring out once the minimum version of the stable ABI that they need, then they can write an autotools macro (or equivalent in other build systems). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Empty directory is a namespace?
On 23.06.2012 17:58, Antoine Pitrou wrote: > On Sat, 23 Jun 2012 17:55:24 +0200 > mar...@v.loewis.de wrote: >>> That's true. I would have hoped for it to be recognized only when >>> there's at least one module or package inside, but it doesn't sound >>> easy to check for (especially in the recursive namespace packages case >>> - is that possible?). >> >> Yes - a directory becomes a namespace package by not having an __init__.py, >> so the "namespace package" case will likely become the default, and people >> will start removing the empty __init__.pys when they don't need to support >> 3.2- anymore. > > Have you tested the performance of namespace packages compared to > normal packages? No, I haven'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] Restricted API versioning
On Sun, Jun 24, 2012 at 5:08 PM, Nick Coghlan wrote: > On Sun, Jun 24, 2012 at 5:00 PM, "Martin v. Löwis" wrote: >>> This strikes me as in opposition to the Python-level policy of duck >>> typing. Would it be more appropriate to, instead of asking if it's >>> Python 3.3.0, ask if it's a Python that supports PY_FEATURE_FOOBAR? Or >>> would that result in an unnecessary proliferation of flag macros? >> >> It would, hence I'm -1. I believe it is the motivation for the gcc >> assertion preprocessor feature, which never caught on. > > Right, if someone wants to check for a specific feature rather than > just figuring out once the minimum version of the stable ABI that they > need, then they can write an autotools macro (or equivalent in other > build systems). Fair enough. I assume these sorts of things are only ever going to be added once, and not backported to old versions, so a single version number is guaranteed to suffice (it's not like "available in 4.5.6 and 4.6.2 and 4.7.4"). Go with the easy option! ChrisA ___ 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] Restricted API versioning
On Jun 24, 2012, at 12:08 AM, Martin v. Löwis wrote: >Please propose something. I think the hexversion *is* user-friendly, >since it allows easy comparisons (Py_LIMITED_API+0 >= 0x0303). >Users that run into missing symbols will, after inspection of the >header file, easily know what to do. +1 for hexversion for the reasons Martin states. -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
[Python-Dev] Offer of help: http://bugs.python.org/issue10910
I see that issue 10910 needs a reviewer for a patch. I know the python code and C++ and offer to review any patches to fix this issue. Having updated Xcode on my Mac I'm having to code workarounds for this issue. My understanding is that you cannot define ispace, toupper etc as macros in C++ environment. These are defined as functions in C++. The minimum patch would #ifdef out the offending lines in byte_methods.h and pyport.h if compiling for C++. I'm going to be releasing a PyCXX release to work around this issue. 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] Offer of help: http://bugs.python.org/issue10910
On 24.06.2012 14:52, Barry Scott wrote: > I see that issue 10910 needs a reviewer for a patch. > > I know the python code and C++ and offer to review > any patches to fix this issue. Is this even an issue for 3.x? ISTM that the C library macros aren't used, anyway, so I think this entire section could go from the header files. For 2.7, things are more difficult. 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] [Python-checkins] cpython: Issue #15102: find python.exe in OutDir, not SolutionDir.
> --- a/PCbuild/pyproject.props > +++ b/PCbuild/pyproject.props > @@ -2,7 +2,7 @@ > xmlns="http://schemas.microsoft.com/developer/msbuild/2003";> > > python33$(PyDebugExt) > - $(SolutionDir)python$(PyDebugExt).exe > + $(OutDir)python$(PyDebugExt).exe > $(OutDir)kill_python$(PyDebugExt).exe > ..\.. > $(externalsDir)\sqlite-3.7.12 In order for this change to accurately reflect the OutDir in the x64 builds, all imports of x64.props need to be moved to be before the pyproject.props import statements. ___ 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] 3.3 release plans
On 06/23/2012 06:54 AM, g.brandl-nos...@gmx.net wrote: > I've decided to make Tuesday 26th the big release day. That means: > > - Saturday: last feature-level changes that should be done before beta, > e.g. removal of packaging > - Sunday: final feature freeze, bug fixing What's your timeframe for bug fixes today? I'd very much like to fix http://bugs.python.org/issue15039, but it will probably take me another 2 hours or so. 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] 3.3 release plans
On Sun, 24 Jun 2012 11:05:35 -0400 "Eric V. Smith" wrote: > On 06/23/2012 06:54 AM, g.brandl-nos...@gmx.net wrote: > > I've decided to make Tuesday 26th the big release day. That means: > > > > - Saturday: last feature-level changes that should be done before beta, > > e.g. removal of packaging > > - Sunday: final feature freeze, bug fixing > > What's your timeframe for bug fixes today? I'd very much like to fix > http://bugs.python.org/issue15039, but it will probably take me another > 2 hours or so. If it's a bugfix, it's not blocked by the feature freeze at all: you can commit after beta (but you might want the bugfix to be in the beta). 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] 3.3 release plans
On 6/24/2012 11:27 AM, Antoine Pitrou wrote: >> What's your timeframe for bug fixes today? I'd very much like to fix >> http://bugs.python.org/issue15039, but it will probably take me another >> 2 hours or so. > > If it's a bugfix, it's not blocked by the feature freeze at all: you > can commit after beta (but you might want the bugfix to be in the beta). Indeed, that's what I'm after: the fix in the beta. I'll do my best to get it in, but obviously it's not a blocker. 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] Offer of help: http://bugs.python.org/issue10910
>> Is this even an issue for 3.x? ISTM that the C library macros aren't >> used, anyway, so I think this entire section could go from the header >> files. > > $ grep isspace > /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/*.h > /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#undef > isspace > /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#define > isspace(c) iswspace(btowc(c)) > > I'm not familiar with pyport.h usage. I do see that it protects the problem > lines with: > #ifdef _PY_PORT_CTYPE_UTF8_ISSUE I think you missed my point. Python shouldn't be using isspace anymore at all, so any work-arounds for certain BSD versions should be outdated and can be removed entirely. Of course, before implementing that solution, one would have to verify that this claim (macros not used) is indeed true. > So long as that is not defined when C++ is in use no problem. I'm not so much concerned with compiling with C++, but care about a potential cleanup of the headers. >> For 2.7, things are more difficult. > > This is where a fix is required. Is there going to be another 2.7 release to > deliver a fix in? Yes, there will be more 2.7 bugfix releases. If a fix is too intrusive or too hacky, it might be that the bug must stay unfixed, though. 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] Offer of help: http://bugs.python.org/issue10910
On 24 Jun 2012, at 14:29, Martin v. Löwis wrote: > On 24.06.2012 14:52, Barry Scott wrote: >> I see that issue 10910 needs a reviewer for a patch. >> >> I know the python code and C++ and offer to review >> any patches to fix this issue. > > Is this even an issue for 3.x? ISTM that the C library macros aren't > used, anyway, so I think this entire section could go from the header > files. $ grep isspace /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/*.h /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#undef isspace /Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/pyport.h:#define isspace(c) iswspace(btowc(c)) I'm not familiar with pyport.h usage. I do see that it protects the problem lines with: #ifdef _PY_PORT_CTYPE_UTF8_ISSUE So long as that is not defined when C++ is in use no problem. > > For 2.7, things are more difficult. This is where a fix is required. Is there going to be another 2.7 release to deliver a fix in? 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] Empty directory is a namespace?
On Sun, Jun 24, 2012 at 3:51 AM, "Martin v. Löwis" wrote: > On 23.06.2012 17:58, Antoine Pitrou wrote: > > On Sat, 23 Jun 2012 17:55:24 +0200 > > mar...@v.loewis.de wrote: > >>> That's true. I would have hoped for it to be recognized only when > >>> there's at least one module or package inside, but it doesn't sound > >>> easy to check for (especially in the recursive namespace packages case > >>> - is that possible?). > >> > >> Yes - a directory becomes a namespace package by not having an > __init__.py, > >> so the "namespace package" case will likely become the default, and > people > >> will start removing the empty __init__.pys when they don't need to > support > >> 3.2- anymore. > > > > Have you tested the performance of namespace packages compared to > > normal packages? > > No, I haven't. > It's probably not worthwhile; any performance cost increase due to looking at more sys.path entries should be offset by the speedup of any subsequent imports from later sys.path entries. Or, to put it another way, almost all the extra I/O cost of namespace packages is paid only once, for the *first* namespace package imported. In effect, this means that the amortized cost of using namespace packages actually *decreases* as namespace packages become more popular. Also, the total extra overhead equals the cost of a listdir() for each directory on sys.path that would otherwise not have been checked for an import. (So, for example, if even one import fails over the life of a program's execution, or it performs even one import from the last directory on sys.path, then there is no actual extra overhead.) Of course, there are still cache validation stat() calls, and they make the cost of an initial import of a namespace package (vs. a self-contained package with __init__.py) to be an extra N stat() calls, where N is the number of sys.path entries that appear *after* the sys.path directory where the package is found. (This cost of course must still be compared against the costs of finding, opening, and running an empty __init__.py[co] file, so it may actually still be quite competitive in many cases.) For imports *within* a namespace package, similar considerations apply, except that N is smaller, and in the simple case of replacing a self-contained package with a namespace (but not adding any additional path locations), N will be zero, making imports from inside the namespace run exactly as quickly as normal imports. In short, it's not worth worrying about, and definitely nothing that should cause people to spread an idea that __init__.py somehow speeds things up. If there's a difference, it'll likely be lost in measurement noise, due to importlib's new directory caching mechanism. ___ 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] Empty directory is a namespace?
On Sun, 24 Jun 2012 13:44:52 -0400 PJ Eby wrote: > On Sun, Jun 24, 2012 at 3:51 AM, "Martin v. Löwis" wrote: > > > On 23.06.2012 17:58, Antoine Pitrou wrote: > > > On Sat, 23 Jun 2012 17:55:24 +0200 > > > mar...@v.loewis.de wrote: > > >>> That's true. I would have hoped for it to be recognized only when > > >>> there's at least one module or package inside, but it doesn't sound > > >>> easy to check for (especially in the recursive namespace packages case > > >>> - is that possible?). > > >> > > >> Yes - a directory becomes a namespace package by not having an > > __init__.py, > > >> so the "namespace package" case will likely become the default, and > > people > > >> will start removing the empty __init__.pys when they don't need to > > support > > >> 3.2- anymore. > > > > > > Have you tested the performance of namespace packages compared to > > > normal packages? > > > > No, I haven't. > > > > It's probably not worthwhile; any performance cost increase due to looking > at more sys.path entries should be offset by the speedup of any subsequent > imports from later sys.path entries. > > Or, to put it another way, almost all the extra I/O cost of namespace > packages is paid only once, for the *first* namespace package imported. And how about CPU cost? > In short, it's not worth worrying about, and definitely nothing that > should cause people to spread an idea that __init__.py somehow speeds > things up. The best way to avoid people spreading that idea would be to show hard measurements. 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] OS X buildbots
Hello, We only have a x86 Tiger OS X buildbot left. People wanting to see OS X supported may decide to maintain a buildbot that will help us avoid regressions. See http://wiki.python.org/moin/BuildBot 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] Empty directory is a namespace?
>> In short, it's not worth worrying about, and definitely nothing that >> should cause people to spread an idea that __init__.py somehow speeds >> things up. > > The best way to avoid people spreading that idea would be to show hard > measurements. PJE wants people to spread an idea, not to avoid them doing so. In any case, hard measurements might help to spread the idea, here are mine. For the attached project, ec656d79b8ac gives, on my system import time for a namespace package: 113µs (fastest run, hot caches) import time for a regular package: 128µs ( " --) first-time import of regular package: 1859µs (due to pyc generation) (remove __init__.py and __pycache__ to construct the first setup) So namespace packages are indeed faster than regular packages, at least in some cases. Regards, Martin spacetiming.tgz Description: application/compressed-tar ___ 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] Empty directory is a namespace?
On Sun, Jun 24, 2012 at 3:27 PM, "Martin v. Löwis" wrote: > >> In short, it's not worth worrying about, and definitely nothing that > >> should cause people to spread an idea that __init__.py somehow speeds > >> things up. > > > > The best way to avoid people spreading that idea would be to show hard > > measurements. > > PJE wants people to spread an idea, not to avoid them doing so. > > In any case, hard measurements might help to spread the idea, here are > mine. For the attached project, ec656d79b8ac gives, on my system > > import time for a namespace package: 113盜 (fastest run, hot caches) > import time for a regular package: 128盜 ( " --) > first-time import of regular package: 1859盜 (due to pyc generation) > (remove __init__.py and __pycache__ to construct the first setup) > > So namespace packages are indeed faster than regular packages, at least > in some cases. > I don't really want to spread the idea that they're faster, either: the exact same benchmark can probably be made to turn out differently if you have, say, a hundred unzipped eggs on sys.path after the benchmark directory. A more realistic benchmark would import more than one module, though... and then it goes back and forth, dueling benchmarks that can always be argued against with a different benchmark measuring different things with other setup conditions. That's what I meant by "lost in the noise": the outcome of the benchmark depends on which of many potentially-plausible setups and applications you choose to use as your basis for measurement, so it's silly to think that either omitting or including __init__.py should be done for performance reasons. Do whatever your application needs, because it's not going to make much difference either way in any realistic program. ___ 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] Empty directory is a namespace?
Le dimanche 24 juin 2012 à 15:51 -0400, PJ Eby a écrit : > > I don't really want to spread the idea that they're faster, either: > the exact same benchmark can probably be made to turn out differently > if you have, say, a hundred unzipped eggs on sys.path after the > benchmark directory. Yes, the case where sys.path is long (thanks to setuptools) is precisely what I was thinking about. > A more realistic benchmark would import more than one module, > though... Indeed. > That's what I meant by "lost in the noise": the outcome of the > benchmark depends on which of many potentially-plausible setups and > applications you choose to use as your basis for measurement, Should we forget to care about performance, just because different setups might yield different results? That's a rather unconstructive attitude. 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] 3.3 feature freeze
Hi all, please consider the default branch frozen for new features as of now. As you know, this also includes changes like large cleanups that cannot be considered bug fixes. Contact me directly (IRC or mail) with urgent questions regarding the release. I hope that we will see the branch (and the buildbots) calm down and stabilize a bit tomorrow, so that everything is ready for Tuesday. cheers, Georg -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ 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] Empty directory is a namespace?
> Should we forget to care about performance, just because different > setups might yield different results? No, we are not forgetting about performance. You asked for a benchmark, I presented one. I fail to see your problem. I claim that the performance of namespace packages is just fine, and presented a benchmark. PJE claims that the performance of namespace packages is fine, and provided reasoning. If you want to see two specific scenarios compared, provide *at least* a description of what these scenarios are. Better, just do the benchmark then yourself. In general, I think there is a widespread misunderstanding how new features impact performance. There are really several cases to be considered: 1.what is the impact of feature on existing applications which don't use it. This is difficult to measure since you first need to construct an implementation which doesn't have the feature, but is otherwise identical. This is often easy to reason about, though. 2,what is the performance of the feature when it is used. This is easy to measure, but difficult to evaluate. If you measure it, and you get some result - is that good, good enough, or bad? For 1, it may be tempting to compare the new implementation with the previous release. However, in the specific case, this is misleading, since the entire import machinery was replaced. So you really need to compare with a version of importlib that doesn't have namespace packages. 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] 3.3 release plans
On 6/24/2012 11:44 AM, Eric V. Smith wrote: > On 6/24/2012 11:27 AM, Antoine Pitrou wrote: >>> What's your timeframe for bug fixes today? I'd very much like to fix >>> http://bugs.python.org/issue15039, but it will probably take me another >>> 2 hours or so. >> >> If it's a bugfix, it's not blocked by the feature freeze at all: you >> can commit after beta (but you might want the bugfix to be in the beta). > > Indeed, that's what I'm after: the fix in the beta. I'll do my best to > get it in, but obviously it's not a blocker. And, no surprise: it's harder to fix than I thought. It won't make it in to the beta. 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] 3.3 release plans
On Mon, Jun 25, 2012 at 6:14 AM, Eric V. Smith wrote: > On 6/24/2012 11:44 AM, Eric V. Smith wrote: >> On 6/24/2012 11:27 AM, Antoine Pitrou wrote: What's your timeframe for bug fixes today? I'd very much like to fix http://bugs.python.org/issue15039, but it will probably take me another 2 hours or so. >>> >>> If it's a bugfix, it's not blocked by the feature freeze at all: you >>> can commit after beta (but you might want the bugfix to be in the beta). >> >> Indeed, that's what I'm after: the fix in the beta. I'll do my best to >> get it in, but obviously it's not a blocker. > > And, no surprise: it's harder to fix than I thought. It won't make it in > to the beta. FWIW, the way I'll often handle that kind of change is to temporarily set it to "release-blocker" (so the RM will at least look at it before deciding whether or not to proceed with the release), and then drop it down to "deferred blocker" if I decide it's not going to be ready, but want to commit to getting it fixed before the *next* release. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] 3.3 release plans
On 06/24/2012 08:32 PM, Nick Coghlan wrote: > On Mon, Jun 25, 2012 at 6:14 AM, Eric V. Smith wrote: >> On 6/24/2012 11:44 AM, Eric V. Smith wrote: >>> On 6/24/2012 11:27 AM, Antoine Pitrou wrote: > What's your timeframe for bug fixes today? I'd very much like to fix > http://bugs.python.org/issue15039, but it will probably take me another > 2 hours or so. If it's a bugfix, it's not blocked by the feature freeze at all: you can commit after beta (but you might want the bugfix to be in the beta). >>> >>> Indeed, that's what I'm after: the fix in the beta. I'll do my best to >>> get it in, but obviously it's not a blocker. >> >> And, no surprise: it's harder to fix than I thought. It won't make it in >> to the beta. > > FWIW, the way I'll often handle that kind of change is to temporarily > set it to "release-blocker" (so the RM will at least look at it before > deciding whether or not to proceed with the release), and then drop it > down to "deferred blocker" if I decide it's not going to be ready, but > want to commit to getting it fixed before the *next* release. Thanks. I was going to make it a deferred blocker, but I managed to come up with a fix in time (I hope!). 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
[Python-Dev] Error in buildbot link
http://docs.python.org/devguide/buildbots.html contains a link to http://python.org/dev/buildbot/, which redirects to http://buildbot.python.org/index.html, which gives a 404. I think it should point to http://buildbot.python.org/all/waterfall, or maybe some subset of it. 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] [Python-checkins] cpython: Issue #15164: Change return value of platform.uname() from a
On Mon, Jun 25, 2012 at 7:31 AM, larry.hastings wrote: > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -59,9 +59,8 @@ > Library > --- > > -- Support Mageia Linux in the platform module. > - > -- Issue #11678: Support Arch linux in the platform module. > +- Issue #15164: Change return value of platform.uname() from a > + plain tuple to a collections.namedtuple. Larry, I think this commit accidentally reverted a couple of entries in Misc/NEWS. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [Python-checkins] cpython: Issue #15164: Change return value of platform.uname() from a
On 06/24/2012 07:21 PM, Nick Coghlan wrote: Larry, I think this commit accidentally reverted a couple of entries in Misc/NEWS. It did; I restored them in the subsequent commit. It's been a hectic couple of days, //arry/ ___ 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] [Python-checkins] peps: Mark PEP 362 as accepted. Huzzah!
Hey Larry, > http://hg.python.org/peps/rev/5019413bf672 > user:Larry Hastings > date:Fri Jun 22 15:16:35 2012 -0700 > summary: > Mark PEP 362 as accepted. Huzzah! > diff --git a/pep-0362.txt b/pep-0362.txt > --- a/pep-0362.txt > +++ b/pep-0362.txt > @@ -4,7 +4,7 @@ > Last-Modified: $Date$ > Author: Brett Cannon , Jiwon Seo , > Yury Selivanov , Larry Hastings > > -Status: Draft > +Status: Final > Type: Standards Track > Content-Type: text/x-rst > Created: 21-Aug-2006 > @@ -546,12 +546,19 @@ > > return wrapper > > +Acceptance > +== > + > +PEP 362 was accepted by Guido, Friday, June 22, 2012 [#accepted]_ . > +The reference implementation was committed to trunk later that day. A PEP header is now required for accepted PEPs: http://www.python.org/dev/peps/pep-0001/#pep-header-preamble . Many PEPs accepted these last months don’t comply with that new rule though. a-kitten-dies-everytime-you-apply-a-subversion-term-to-mercurial’ly yours ___ 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
