Re: [Python-Dev] PEP 3003 - Python Language Moratorium
~b <[email protected]> <[email protected]> <20091106001430.3229.796306500.divmod.xquotient@localhost.localdomain> <[email protected]> <[email protected]> <20091106140412.3229.80002680.divmod.xquotient@localhost.localdomain> <[email protected]> <20091106215210.3229.1142452245.divmod.xquotient@localhost.localdomain> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" d20e0a45a4b2 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 07 Nov 2009 17:35:21 +0900 Message-ID: <[email protected]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii [email protected] writes: > How would you collect this information? Would you run the test suite > for each project? This would reward projects with small or absent test > suites. ;) Multiply by the number of lines of code and divide by the number of tests run. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the Buildbot fleet and related bugs
On Nov 6, 2009, at 6:34 PM, Georg Brandl wrote: R. David Murray schrieb: So, overall I think the buildbot fleet is in good shape, and if we can nail issue 6748 I think it will be back to being an important resource for sanity checking our checkins. Yay! Thanks to all of you! Indeed! It's great to see so much work going into build and test maintenance. Thanks a lot! ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
On Nov 6, 2009, at 4:52 PM, [email protected] wrote: On 09:48 pm, [email protected] wrote: On Fri, 6 Nov 2009 at 15:48, Glyph Lefkowitz wrote: Documentation would be great, but then you have to get people to read the documentation and that's kind of tricky. Better would be for every project on PyPI to have a score which listed warnings emitted with each version of Python. People love optimizing for stuff like that and comparing it. I suspect that even if all warnings were completely silent by default, developers would suddenly become keenly interested in fixing them if there were a metric like that publicly posted somewhere :). +1, but somebody needs to write the code... How would you collect this information? Would you run the test suite for each project? This would reward projects with small or absent test suites. ;) *I* would not collect this information, as I am far enough behind on other projects ;-) but I if I were to advise someone *else* as to how to do it, I'd probably add a feature to the 'warnings' module where users could opt-in (sort of like popcon.debian.org) to report warnings encountered during normal invocations of any of their Python programs. I would also advise such a hypothetical data-gathering project to start with a buildbot doing coverage runs; any warning during the test suite would be 1 demerit, any warning during an actual end-user run of the application *not* caught by the test suite would be 1000 demerits :). And actually it would make more sense if this were part of an overall quality metric, like http://pycheesecake.org/ proposes (although I think that cheesecake's current metric is not really that great, the idea is wonderful). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reworking the GIL
Hi Antoine, I was finally able to compile py3k and run the benchmark (my compilation issue was caused by checking out on Windows and compiling on Unix. Some Makefile templates are missing correct EOL properties in SVN I think). The benchmark results can be obtained from: http://gaiacrtn.free.fr/py/benchmark-newgil/benchmark-newgil.tar.bz2 and viewed from: http://gaiacrtn.free.fr/py/benchmark-newgil/ I ran the benchmark on two platforms: - Solaris X86, 16 cores: some python extension are likely missing (see config.log) - Windows XP SP3, 4 cores: all python extensions but TCL (I didn't bother checking why it failed as it is not used in the benchmark). It is a release build. The results look promising but I let you share your conclusion (some latency results seem a bit strange from my understanding). Side-note: PCBuild requires nasmw.exe but it no longer exists in the latest version. I had to rename nasm.exe to nasmw.exe. Would be nice to add this to the readme to avoid confusion... Baptiste. 2009/11/1 Antoine Pitrou > > Hello again, > > Brett Cannon python.org> writes: > > > > I think it's worth it. Removal of the GIL is a totally open-ended problem > > with no solution in sight. This, on the other hand, is a performance > benefit > > now. I say move forward with this. If it happens to be short-lived > because > > some actually figures out how to remove the GIL then great, but is that > > really going to happen between now and Python 3.2? I doubt it. > > Based on this whole discussion, I think I am going to merge the new GIL > work > into the py3k branch, with priority requests disabled. > ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
Guido> ... it's IMO pretty mysterious if you encounter this and don't Guido> already happen to know what it means. If you require parens maybe it parses better: import (a or b or c) as mod Given that the or operator shortcuts I think that (a or b or c) terminates once a module is found isn't too hard to grasp. Skip ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
On 12:10 pm, [email protected] wrote: Guido> ... it's IMO pretty mysterious if you encounter this and don't Guido> already happen to know what it means. If you require parens maybe it parses better: import (a or b or c) as mod Given that the or operator shortcuts I think that (a or b or c) terminates once a module is found isn't too hard to grasp. Did everyone forget what the subject of this thread is? Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] People want CPAN :-)
On Nov 7, 2009, at 3:20 AM, Ben Finney wrote: Guido van Rossum writes: On Fri, Nov 6, 2009 at 2:52 PM, David Lyon wrote: I think buildbot-style test runs for PyPI packages would raise average package quality on PyPI. Please excuse the cross-post but I wanted to make sure that all these "CPAN for Python" discussions got this message and I've lost track of which list which part of what discussion had occurred on. We are currently extending our distutils/Distribute test system to include installation of a broad range of packages as part of the pre- release process for a future release of Distribute and as part of our "smoke" test for distutils/Distribute.Eventually, the goal is to integrate this with our buildbot system but that's a ways off. Our goal is to install a range of packages and, where practicable, actually run and record any errors with the packages' individual test suites. Right now, our "smoke" test only does Twisted and numpy. We've discussed how to collect test results from Twisted trial and we'll be working on similar things for other test runners (nose et al.). For Twisted, we're going to install and test both the current release version and an svn checkout from trunk. It would be an extension of that concept to install and test *all* packages from PyPI but would, obviously, take considerable horsepower (and time) to run such an exhaustive test (especially if we're talking about 2.4?, 2.5, 2.6, 2.7, and 3.1+. Right now I'm extending the configuration file for our smoke test to allow for various test runners (e.g. nose, twisted trial, etc.) so we can "smoke out" more installation problems and/or failed tests after installation. For the first pass, I'm just focusing on Twisted and trial, then numpy, then finding packages that support nose so that I can collect the data on what ran, what passed, and what didn't. I'm planning on collecting this all in a database and making some simple API so that it can be mined by very simple apps later. At the point where that infrastructure is in place, we could pretty easily mine the data to do all kinds of crazy things people have mentioned like: * A ranking system of test coverage * Complexity analysis * Test coverage * Run pylint, pyflakes, 2to3, whatever automated measurement tools over the code * Send test failure messages to maintainers (maybe with opt-in in the new meta-data). * Whatever! We're actively working on this right now; anyone who wants to lend a hand is welcome to contact me off-list and we can talk about what types of things we are needing and where we could use a hand. All in all, I think this could be a big leap forward for the Python distribution ecosystem whether or not we eventually write the PyPan I wished for as a new Perl refugee. Thanks, S ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reworking the GIL
Hello, > Solaris X86, 16 cores: some python extension are likely missing (see config.log) > Windows XP SP3, 4 cores: all python extensions but TCL (I didn't bother checking why it failed as it is not used in the benchmark). It is a release build. > > The results look promising but I let you share your conclusion (some latency results seem a bit strange from my understanding). Thank you! The latency results don't look that strange to me. If you're surprised that py3k shows better latency than newgil on the "pi calculation" workload, it's easy to understand why: py3k speculatively releases the GIL so often on that workload (every 100 opcodes) that the latencies are indeed very good, but if you look at the corresponding throughput numbers they are dismal (your Solaris box shows it falling to less than 20% with two threads running compared to the baseline number for single-thread execution, and on your Windows box the number is hardly better with 45%). So, to sum it up, the way the current GIL manages to have good latencies is by issueing an unreasonable number of system calls on a contended lock, and potentially killing throughput performance (this depends on the OS too, because numbers under Linux are not so catastrophic). The new GIL, on the other hand, is much more balanced in that it achieves rather predictable latencies (especially when you don't overcommit the OS by issueing more computational threads than you have CPU cores) while preserving throughput performance. > Side-note: PCBuild requires nasmw.exe but it no longer exists in the latest > version. I had to rename nasm.exe to nasmw.exe. Would be nice to add this to > the readme to avoid confusion... You should file a bug on http://bugs.python.org Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] People want CPAN :-)
On Sat, Nov 7, 2009 at 9:30 AM, [email protected] wrote: > On Nov 7, 2009, at 3:20 AM, Ben Finney wrote: > >> Guido van Rossum writes: >> >>> On Fri, Nov 6, 2009 at 2:52 PM, David Lyon >>> wrote: >> I think buildbot-style test runs for PyPI packages would raise average >> package quality on PyPI. > > Please excuse the cross-post but I wanted to make sure that all these "CPAN > for Python" discussions got this message and I've lost track of which list > which part of what discussion had occurred on. > > We are currently extending our distutils/Distribute test system to include > installation of a broad range of packages as part of the pre-release process > for a future release of Distribute and as part of our "smoke" test for > distutils/Distribute. Eventually, the goal is to integrate this with our > buildbot system but that's a ways off. Who is "we"? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] People want CPAN :-)
On Nov 7, 2009, at 10:08 AM, Jesse Noller wrote: On Sat, Nov 7, 2009 at 9:30 AM, [email protected] > wrote: On Nov 7, 2009, at 3:20 AM, Ben Finney wrote: Guido van Rossum writes: On Fri, Nov 6, 2009 at 2:52 PM, David Lyon > wrote: I think buildbot-style test runs for PyPI packages would raise average package quality on PyPI. Please excuse the cross-post but I wanted to make sure that all these "CPAN for Python" discussions got this message and I've lost track of which list which part of what discussion had occurred on. We are currently extending our distutils/Distribute test system to include installation of a broad range of packages as part of the pre- release process for a future release of Distribute and as part of our "smoke" test for distutils/Distribute.Eventually, the goal is to integrate this with our buildbot system but that's a ways off. Who is "we"? We is the people working on Distribute/distutils. S ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reworking the GIL
Antoine, How close are you to merging this into the Py3k branch? It looks like a solid piece of work, that can only get better in the period between now and the release of 3.2. But I don't want to rush you, and I only have had a brief look at your code. (I whipped up a small Dave Beazley example and was impressed by the performance of your code compared to the original py3k branch -- from 150% to 100% CPU usage according to top with only 2 threads.) My only suggestion so far: the description could use more explicit documentation on the various variables and macros and how they combine. I also expect that priority requests aren't important; it somehow seems strange that if multiple threads are all doing I/O each new thread whose I/O completes would get to preempt whoever else is active immediately. (Also the choice of *not* making a priority request when a read returns no bytes seems strange 00 if I read the code correctly.) Anyway, thanks for this work! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
[email protected] schrieb: > On 12:10 pm, [email protected] wrote: >>Guido> ... it's IMO pretty mysterious if you encounter this and >>don't >>Guido> already happen to know what it means. >> >>If you require parens maybe it parses better: >> >>import (a or b or c) as mod >> >>Given that the or operator shortcuts I think that (a or b or c) >>terminates >>once a module is found isn't too hard to grasp. > > Did everyone forget what the subject of this thread is? Why? The subject of this thread is "Importing module alternatives cleanly". We just happened to forget adapting the "Subject:" line. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reworking the GIL
Hello Guido, > How close are you to merging this into the Py3k branch? It looks like > a solid piece of work, that can only get better in the period between > now and the release of 3.2. But I don't want to rush you, and I only > have had a brief look at your code. The code is ready. Priority requests are already disabled, I'm just wondering whether to remove them from the code, or leave them there in case someone thinks they're useful. I suppose removing them is ok. > My only suggestion so far: the description could use more explicit > documentation on the various variables and macros and how they > combine. Is it before or after http://mail.python.org/pipermail/python-checkins/2009-November/087482.html ? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reworking the GIL
On Sat, Nov 7, 2009 at 9:01 AM, Antoine Pitrou wrote: > > Hello Guido, > >> How close are you to merging this into the Py3k branch? It looks like >> a solid piece of work, that can only get better in the period between >> now and the release of 3.2. But I don't want to rush you, and I only >> have had a brief look at your code. > > The code is ready. Priority requests are already disabled, I'm just > wondering whether to remove them from the code, or leave them there in > case someone thinks they're useful. I suppose removing them is ok. I would remove them -- if and when we find there's a need for something like them I suspect it won't look like what you currently have, so it's better not to complexificate your current patch with them. (I would remove all traces, including the conditions passed into the end macros.) >> My only suggestion so far: the description could use more explicit >> documentation on the various variables and macros and how they >> combine. > > Is it before or after > http://mail.python.org/pipermail/python-checkins/2009-November/087482.html ? After. While that is already really helpful, not all the code is easily linked back to paragraphs in that comment block, and some variables are not mentioned by name in the block. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reworking the GIL
2009/11/7 Antoine Pitrou > > [...] > So, to sum it up, the way the current GIL manages to have good latencies is > by > issueing an unreasonable number of system calls on a contended lock, and > potentially killing throughput performance (this depends on the OS too, > because > numbers under Linux are not so catastrophic). > Ah, I remember reading this in the analysis that was published now! I made another benchmark using one of my script I ported to python 3 (and simplified a bit). I only test the total execution time. Tests done on Windows XP SP3. Processor is an Intel Core 2 Quad Q9300 (4 cores). You can get the script from: http://gaiacrtn.free.fr/py/benchmark-kwd-newgil/purekeyword-py26-3k.py Script + test doc (940KB): http://gaiacrtn.free.fr/py/benchmark-kwd-newgil/benchmark-kwd-newgil.tar.bz2 The threaded loop is: for match in self.punctuation_pattern.finditer( document ): word = document[last_start_index:match.start()] if len(word) > 1 and len(word) < MAX_KEYWORD_LENGTH: words[word] = words.get(word, 0) + 1 last_start_index = match.end() if word: word_count += 1 Here are the results: -j0 (main thread only) 2.5.2 : 17.991s, 17.947s, 17.780s 2.6.2 : 19.071s, 19.023s, 19.054s 3.1.1 : 46.384s, 46.321s, 46.425s newgil: 47.483s, 47.605s, 47.512s -j4 (4 consumer threads, main thread producing/waiting) 2.5.2 : 31.105s, 30.568s 2.6.2 : 31.550s, 30.599s 3.1.1 : 85.114s, 85.185s newgil: 48.428s, 49.217s It shows that, on my platform for this specific benchmark: - newgil manage to leverage a significant amount of parallelism (1.7) where python 3.1 does not (3.1 is 80% slower) - newgil as a small impact on non multi-threaded execution (~1-2%) [may be worth investigating] - 3.1 is more than 2 times slower than python 2.6 on this benchmark - 2.6 is "only" 65% slower when run with multiple threads compared to the 80% slower of 3.1. Newgil is a vast improvement as it manages to leverage the short time the GIL is released by finditer [if I understood correctly in 3.x regex release the GIL]. What's worry me is the single threaded performance degradation between 2.6 and 3.1 on this test. Could the added GIL release/acquire on each finditer call explain this? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reworking the GIL
Hello again, > It shows that, on my platform for this specific benchmark: > * newgil manage to leverage a significant amount of parallelism > (1.7) where python 3.1 does not (3.1 is 80% slower) I think you are mistaken: -j0 (main thread only) newgil: 47.483s, 47.605s, 47.512s -j4 (4 consumer threads, main thread producing/waiting) newgil: 48.428s, 49.217s The runtimes are actually the same, so newgil doesn't leverage anything. However, it doesn't degrade performance like 2.x/3.1 does :-) > * newgil as a small impact on non multi-threaded execution > (~1-2%) [may be worth investigating] It goes from very slightly slower to very slightly faster and it is likely to be caused by variations in generated output from the compiler. > * 3.1 is more than 2 times slower than python 2.6 on this > benchmark That's the most worrying outcome I'd say. Are you sure the benchmark really does the same thing? Under 2.6, you should add re.UNICODE to the regular expression flags so as to match the 3.x semantics. > [if I understood correctly in 3.x regex release the GIL]. Unless I've missed something it doesn't, no. This could be a separate opportunity for optimization, if someone wants to take a look at it. Regards Antoine. ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
On Fri, 6 Nov 2009 09:05:17 am Guido van Rossum wrote: > On Tue, Nov 3, 2009 at 9:35 AM, Guido van Rossum wrote: > > I've checked draft (!) PEP 3003, "Python Language Moratorium", into > > SVN. As authors I've listed Jesse, Brett and myself. > > I haven't seen substantial opposition against the PEP -- in fact I > can't recall any, and many people have explicitly posted in support > of it. So unless opposition suddenly appears in the next few days, > I'll move it to the Accepted state next Monday. I'm not a core developer, but I have made some objections on the python-ideas list. For what it is worth, I don't think a moratorium is needed, and it is not cost free. Whether the cost is worth it is a matter of opinion, but I've read posts suggesting that there's no downside to a moratorium. I think that's naive. Firstly, the core developers are very conservative in the features they add to the language. Nobody suggests that will change -- there are (as far as I know) a grand total of *one* proposed language changes under consideration for 3.2, namely "yield from". It isn't like the moratorium is needed to stem a flood of vast numbers of incompatible language changes, and this is not likely to change. The given reason for the moratorium is to give the developers of other Python implementations a chance to catch up. But as far as I know -- and I welcome correction -- only one such developer has spoken up, and he says that new language features generally aren't a problem for IronPython, but some standard library features are: http://mail.python.org/pipermail/python-ideas/2009-October/006328.html (In fairness, I should point out that Dino did not vote against the moratorium, he gave a conditional "in favour" vote but asked for some wiggle-room. A moratorium with wiggle-room is not a moratorium.) A moratorium isn't cost-free. With the back-end free to change, patches will go stale over 2+ years. People will lose interest or otherwise move on. Those with good ideas but little patience will be discouraged. I fully expect that, human nature being as it is, those proposing a change, good or bad, will be told not to bother wasting their time, there's a moratorium on at least as often as they'll be encouraged to bide their time while the moratorium is on. A moratorium turns Python's conservativeness up to 11. If Python already has a reputation for being conservative in the features it accepts -- and I think it does -- then a moratorium risks giving the impression that Python has become the language of choice for old guys sitting on their porch yelling at the damn kids to get off the lawn. That's a plus for Cobol. I don't think it is a plus for Python. What one person sees as "stable", another may see as "moribund". Perception does matter. Nick Coglan spoke of Jython having "fell by the wayside" when CPython introduced new style classes: http://mail.python.org/pipermail/python-ideas/2009-October/006431.html I think that speaks to the opposite conclusion that Nick intended. If developers craved stability, and were put off by the pace of changes to CPython, why weren't they migrating to Jython, which had one new production release in six years? http://www.jython.org/archive/22/news.html Nick also described C as changing much more slowly over its life that Python has. This is misleading: it is true that the C standard has been stable, but that doesn't mean that C compilers have been. Changes to the standard were driven by changes introduced by the implementations, not visa versa. Likewise for Cobol, where the first implementation to introduce OOP was released in 1997, but the standard wasn't updated until 2002. Python is nothing like that. Python doesn't have an official standard, and Guido has dismissed the need for an ISO standard. The other implementations have historically let CPython lead as far as language evolution goes. If CPython stops, likely Python stops. Who is going to risk adding language features that break compatibility with the most popular implementation? It won't be Python anymore. The PEP says the moratorium will last "at least" two years from the release of 3.1. Given the normal slow pace of new language features, two years isn't bad -- that's effectively just 3.2. But Guido has suggested it could last to 3.3. Could it last beyond that? 3.4? Until some distant future Python-4000? At the very least, I believe, any moratorium should have a clear end date. A clear end date will be a powerful counter to the impression that Python the language is moribund. It says, this is an exceptional pause, not a permanent halt. -- Steven D'Aprano ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
On Fri, 6 Nov 2009 08:46:00 pm Willem Broekema wrote: > CLPython is in steady development, quite complete and stable on the > language level (somewhere between 2.5 and 2.6), but missing most > built-in library functionality. (It reuses the pure-Python parts of > the stdlib.) > > As its developer, I don't care much about being mentioned in > discussions or presentations, as CLPython is not as widely used as > IronPython and Jython. But in a PEP like this, which is directly > about alternative implementations, it deserves to be mentioned, IMHO. Willem, the rationale for this PEP is to give alternative implementations the chance to catch up with CPython. Given your statement that CLPython is quite complete on the language level, but missing standard library features, how do you think the moratorium will help CLPython? -- Steven D'Aprano ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
... > A moratorium isn't cost-free. With the back-end free to change, patches > will go stale over 2+ years. People will lose interest or otherwise > move on. Those with good ideas but little patience will be discouraged. > I fully expect that, human nature being as it is, those proposing a > change, good or bad, will be told not to bother wasting their time, > there's a moratorium on at least as often as they'll be encouraged to > bide their time while the moratorium is on. > I believe if you go back to the very beginning of this thread, Guido considers this a *feature* not a *bug*. He wanted to introduce a moratorium at least partially because he was tired of endless threads about anonymous code blocks, etc. Which aren't going to be included in the language anyway, so he may as well make a point to say "and neither will anything else for a while". I don't mean to put words into his mouth, so please correct me if I'm wrong. John =:-> ___ Python-Dev mailing list [email protected] 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 3003 - Python Language Moratorium
On Sun, Nov 8, 2009 at 1:16 AM, Steven D'Aprano wrote: > Willem, the rationale for this PEP is to give alternative > implementations the chance to catch up with CPython. > > Given your statement that CLPython is quite complete on the language > level, but missing standard library features, how do you think the > moratorium will help CLPython? It would be great to have a pause in Python-the-language, so that CLPython might at the end of the moratorium finally be up to date with the latest 2.x and 3.x features. Supporting standard libraries is a bigger challenge, as the ones written in C need rewriting. Whether or not there is a pause on that front does not matter too much to that situation. - Willem ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
