Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote: > I think this social problem of the PEP can only be solved if the CPython > project stops doing the major share of the stdlib maintenance, thus freeing > its own developer capacities to focus on CPython related improvements and > optimisations, just like the other implementations currently do. I'm not > sure we want that at this point. We've made a start on that aspect by granting CPython access to several of the core developers on the other VMs. The idea being that they can update the pure Python versions of modules directly rather than having to wait for one of us to do it on their behalf. Of course, as Maciej pointed out, that is currently hindered by the fact that the other VMs aren't targeting 3.3 yet, and that's where the main CPython development is happening. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
Nick Coghlan, 19.04.2011 10:57: On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote: I think this social problem of the PEP can only be solved if the CPython project stops doing the major share of the stdlib maintenance, thus freeing its own developer capacities to focus on CPython related improvements and optimisations, just like the other implementations currently do. I'm not sure we want that at this point. We've made a start on that aspect by granting CPython access to several of the core developers on the other VMs. The idea being that they can update the pure Python versions of modules directly rather than having to wait for one of us to do it on their behalf. Of course, as Maciej pointed out, that is currently hindered by the fact that the other VMs aren't targeting 3.3 yet, and that's where the main CPython development is happening. A related question is: when other Python VM projects try to port a given C module, would they actually invest the time to write a pure Python version that may or may not run within acceptable performance bounds for them, or would they prefer saving time by writing only a native implementation directly for their VM for performance reasons? Maybe both, maybe not. If they end up writing a native version after prototyping in Python, is the prototype worth including in the shared stdlib, even if its performance is completely unacceptable for everyone? Or, if they write a partial module and implement another part of it natively, would the incomplete implementation qualify as a valid addition to the shared stdlib? Implementing a 100% compatible and "fast enough" Python version of a module is actually a rather time consuming task. I think we are expecting some altruism here that is easily sacrificed for time constraints, in any of the Python VM projects. CPython is just in the unlucky position of representing the status-quo. Stefan ___ 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] cpython: os.sendfile(): on Linux if offset parameter is passed as NULL we were
On Tue, 19 Apr 2011 09:47:21 +0200 giampaolo.rodola wrote: > http://hg.python.org/cpython/rev/8c49f7fbba1d > changeset: 69437:8c49f7fbba1d > user:Giampaolo Rodola' > date:Tue Apr 19 09:47:16 2011 +0200 > summary: > os.sendfile(): on Linux if offset parameter is passed as NULL we were > erroneously returning a (bytes_sent, None) tuple instead of bytes_sent Do we have tests for this? 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, Apr 19, 2011 at 1:06 AM, Stefan Behnel wrote: [snip] > This PEP has received a lengthy discussion by now, so here's why I think > it's being fought so heavily by several CPython core developers, > specifically those who have traditionally carried a large part of the > optimisation load in the project. > > I think the whole point of this PEP is that, having agreed that a shared > standard library for all Python implementations is a good thing, the amount > of shareable code should be maximised. I doubt that anyone will argue > against this goal. > > But that obviously includes all sides. If other implementations are free to > cherry pick the targets of their own effort geared by the optimisation of > their own implementation, and leave the whole burden of compatibility and > code reusability on CPython, in addition to the CPython efforts of improving > and optimising its own core code base and its own stdlib version, it's not > an equal matter. > I am going to go out on a limb here and state that once the stdlib is shared, it is all of the VM's responsibility to help maintaining it, meaning the PEP 399 is binding to all of the VMs. If Jython wants to write an accelerator module in Java for something in the stdlib, they have to follow the same guidelines, same applies to PyPy, etc. I think this is an equal matter, and if needed, we should make note of it in the PEP. The goal here is to make it easier to share the code base of the stdlib and not pull the rug out from other implementations by having a stdlib module written only in highly optimized C with no Python fallback, leaving them with the unsavory duty of reimplementing it in Python|Java|C#, etc. Pure Python is the coin of the realm. > That's what makes the PEP feel so unfair to CPython developers, because they > are the ones who carry most of the burden of maintaining the stdlib in the > first place, and who will most likely continue to carry it, because other > implementations will continue to be occupied with their own core development > for another while or two. It is nice to read that other implementations are > contributing back patches that simplify their own reuse of the stdlib code. > However, that does not yet make them equal contributors to the development > and the maintenance of the stdlib, and is of very little worth to the > CPython project. It often even runs counter to the interest of CPython > itself. Sure, at first glance this seems to place an unfair burden on CPython - because we're just as guilty as being "closed" to other implementation as the other implementations are to us. We're trying to change that, and someone (us, as the reference implementation) need to take the first responsible step. Once this move is made/accepted, I would expect the other implementation to rapidly move away from their custom implementations of the stdlib and contribute to the shared code base and documentation. Yes, this places a burden on CPython, but in the long term in benefits *all* of the projects equally by simply having more active contributors. We have over 200 stdlib modules, and far, far less than that in active developers focused or working on the stdlib. Making it a shared property (in theory) means that the other VMs have a shared interest in that property. We're effectively spreading the load. > I think this social problem of the PEP can only be solved if the CPython > project stops doing the major share of the stdlib maintenance, thus freeing > its own developer capacities to focus on CPython related improvements and > optimisations, just like the other implementations currently do. I'm not > sure we want that at this point. That's not going to happen. CPython will continue to do the bulk of the maintenance until we break it out, and the other implementations have time to adapt and pull in the shared code base. I don't see this as such a large burden as you seem to be making it out to be: CPython is the reference implementation, and our stdlib is the reference stdlib. We can break out the stdlib and share it amongst the implementations therefore making it more than the reference stdlib - we can make it the defacto stdlib for the language as a whole. We also, long term, want spread the maintenance load beyond CPython, but right now we are the primary caretakers, so yes - this adds load to us in the short term, but benefits us in the long term. jesse ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, Apr 19, 2011 at 10:57 AM, Nick Coghlan wrote: > On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote: >> I think this social problem of the PEP can only be solved if the CPython >> project stops doing the major share of the stdlib maintenance, thus freeing >> its own developer capacities to focus on CPython related improvements and >> optimisations, just like the other implementations currently do. I'm not >> sure we want that at this point. > > We've made a start on that aspect by granting CPython access to > several of the core developers on the other VMs. The idea being that > they can update the pure Python versions of modules directly rather > than having to wait for one of us to do it on their behalf. > > Of course, as Maciej pointed out, that is currently hindered by the > fact that the other VMs aren't targeting 3.3 yet, and that's where the > main CPython development is happening. We're also slightly hindered by the fact that not all of us got privilages so far (Antonio Cuni in particular). > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com > ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, Apr 19, 2011 at 8:17 AM, Maciej Fijalkowski wrote: > On Tue, Apr 19, 2011 at 10:57 AM, Nick Coghlan wrote: >> On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote: >>> I think this social problem of the PEP can only be solved if the CPython >>> project stops doing the major share of the stdlib maintenance, thus freeing >>> its own developer capacities to focus on CPython related improvements and >>> optimisations, just like the other implementations currently do. I'm not >>> sure we want that at this point. >> >> We've made a start on that aspect by granting CPython access to >> several of the core developers on the other VMs. The idea being that >> they can update the pure Python versions of modules directly rather >> than having to wait for one of us to do it on their behalf. >> >> Of course, as Maciej pointed out, that is currently hindered by the >> fact that the other VMs aren't targeting 3.3 yet, and that's where the >> main CPython development is happening. > > We're also slightly hindered by the fact that not all of us got > privilages so far (Antonio Cuni in particular). Yeah, I emailed him this morning, I dropped the ball on his commit bit post pycon due to email overload. I'm resolving it today. ___ 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] Python 2.6.7
On Mon, Apr 18, 2011 at 3:53 PM, Barry Warsaw wrote: > With Martin getting ready to release 2.5.6, I think it's time to prepare a > 2.6.7 source-only security release. > > I'll work my way through the NEWS file and recent commits, but if there is > anything that you know is missing from the 2.6 branch, please let me know. It > would be especially helpful if there were bugs for any such issues. Does 'anything' only relate to security fixes? -- anatoly t. ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, Apr 19, 2011 at 12:01 PM, Stefan Behnel wrote: > Nick Coghlan, 19.04.2011 10:57: >> >> On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote: >>> >>> I think this social problem of the PEP can only be solved if the CPython >>> project stops doing the major share of the stdlib maintenance, thus >>> freeing >>> its own developer capacities to focus on CPython related improvements and >>> optimisations, just like the other implementations currently do. I'm not >>> sure we want that at this point. >> >> We've made a start on that aspect by granting CPython access to >> several of the core developers on the other VMs. The idea being that >> they can update the pure Python versions of modules directly rather >> than having to wait for one of us to do it on their behalf. >> >> Of course, as Maciej pointed out, that is currently hindered by the >> fact that the other VMs aren't targeting 3.3 yet, and that's where the >> main CPython development is happening. > > A related question is: when other Python VM projects try to port a given C > module, would they actually invest the time to write a pure Python version > that may or may not run within acceptable performance bounds for them, or > would they prefer saving time by writing only a native implementation > directly for their VM for performance reasons? Maybe both, maybe not. If > they end up writing a native version after prototyping in Python, is the > prototype worth including in the shared stdlib, even if its performance is > completely unacceptable for everyone? Or, if they write a partial module and > implement another part of it natively, would the incomplete implementation > qualify as a valid addition to the shared stdlib? At least from our (PyPy's side), we do use pure python versions a lot. Their performance vary, but sometimes you don't care, you just want the module to work. Contrary to popular belief, not all code is performance critical in standard library. We got quite far without even looking. Later on we usually look there, but for us rewriting it in RPython most of the time makes no sense, since pure python code might even behave better than RPython code, especially if there are loops which get jitted more efficiently if they're in pure python. > > Implementing a 100% compatible and "fast enough" Python version of a module > is actually a rather time consuming task. I think we are expecting some > altruism here that is easily sacrificed for time constraints, in any of the > Python VM projects. CPython is just in the unlucky position of representing > the status-quo. I think 100% compatible with whatever performance is already a lot for us. We can improve the performance later on. For example we never touched heapq module and it works just fine as it is. > > Stefan > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com > ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
> > Once this move is made/accepted, I would expect the other > implementation to rapidly move away from their custom implementations > of the stdlib and contribute to the shared code base and > documentation. Yes, this places a burden on CPython, but in the long > term in benefits *all* of the projects equally by simply having more > active contributors. > I would also like to point out that some valuable contributions were made already by other implementations. When talking about stdlib, it's mostly in the area of test suite, but not only in terms of "skip those tests", but also improving test coverage and even fixing bugs. Unicode fixes were prototyped on PyPy first and some PyPy optimizations were ported to CPython (the original method cache patch came from Armin Rigo as far as I remember). So it's not completely "Cpython's burden" only. Cheers, fijal ___ 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] Drop OS/2 and VMS support?
Hi, I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, our OS/2 maintainer, answered: http://mail.python.org/pipermail/python-dev/2010-April/099477.html Extract: << The 3.x branch needs quite a bit of work on OS/2 to deal with Unicode, as OS/2 was one of the earlier OSes with full multiple language support and IBM developed a unique API. I'm still struggling to come to terms with this, partly because I myself don't "need" it. >> So one year later, Python 3 does still not support OS/2. -- About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if Python 3 does work on VMS. I bet that it does just not compile :-) I don't know anyone using VMS or OS/2. -- There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait until someone work on these OSes to ensure that the test suite pass. But if nobody cares of these OSes and nobody wants to maintain them, it would be easier for the maintenance of the Python source code base to remove specific code. Well, not "remove" directly, but plan to remove it using the PEP 11 procedure (mark OS/2 and VMS as unsupported, and remove the code in Python 3.4). Victor ___ 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] Python 2.6.7
On Apr 19, 2011, at 03:25 PM, anatoly techtonik wrote: >On Mon, Apr 18, 2011 at 3:53 PM, Barry Warsaw wrote: >> With Martin getting ready to release 2.5.6, I think it's time to prepare a >> 2.6.7 source-only security release. >> >> I'll work my way through the NEWS file and recent commits, but if there is >> anything that you know is missing from the 2.6 branch, please let me know. >> It >> would be especially helpful if there were bugs for any such issues. > >Does 'anything' only relate to security fixes? Yes. -Barry signature.asc Description: PGP signature ___ 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] Providing a mechanism for PEP 3115 compliant dynamic class creation
In reviewing a fix for the metaclass calculation in __build_class__ [1], I realised that PEP 3115 poses a potential problem for the common practice of using "type(name, bases, ns)" for dynamic class creation. Specifically, if one of the base classes has a metaclass with a significant __prepare__() method, then the current idiom will do the wrong thing (and most likely fail as a result), since "ns" will probably be an ordinary dictionary instead of whatever __prepare__() would have returned. Initially I was going to suggest making __build_class__ part of the language definition rather than a CPython implementation detail, but then I realised that various CPython specific elements in its signature made that a bad idea. Instead, I'm thinking along the lines of an "operator.prepare(metaclass, bases)" function that does the metaclass calculation dance, invoking __prepare__() and returning the result if it exists, otherwise returning an ordinary dict. Under the hood we would refactor this so that operator.prepare and __build_class__ were using a shared implementation of the functionality at the C level - it may even be advisable to expose that implementation via the C API as PyType_PrepareNamespace(). The correct idiom for dynamic type creation in a PEP 3115 world would then be: from operator import prepare cls = type(name, bases, prepare(type, bases)) Thoughts? Cheers, Nick. [1] http://bugs.python.org/issue1294232 -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Drop OS/2 and VMS support?
Victor Stinner wrote: > Hi, > > I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, > our OS/2 maintainer, answered: > http://mail.python.org/pipermail/python-dev/2010-April/099477.html > > Extract: << The 3.x branch needs quite a bit of work on OS/2 to > deal with Unicode, as OS/2 was one of the earlier OSes with full > multiple language support and IBM developed a unique API. I'm still > struggling to come to terms with this, partly because I myself don't > "need" it. >> > > So one year later, Python 3 does still not support OS/2. > > -- > > About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if > Python 3 does work on VMS. I bet that it does just not compile :-) > > I don't know anyone using VMS or OS/2. > > -- > > There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait > until someone work on these OSes to ensure that the test suite pass. But > if nobody cares of these OSes and nobody wants to maintain them, it > would be easier for the maintenance of the Python source code base to > remove specific code. > > Well, not "remove" directly, but plan to remove it using the PEP 11 > procedure (mark OS/2 and VMS as unsupported, and remove the code in > Python 3.4). The Python core team is not really representative of the Python community users, so I think this needs a different approach: Instead of simply deprecating OSes without notice to the general Python community, how about doing a "call for support" for these OSes ? If that doesn't turn up maintainers, then we can take the PEP 11 route. FWIW: There's still a fan-base out there for OS/2 and its successor eComStation: http://en.wikipedia.org/wiki/EComStation http://www.ecomstation.com/ecomstation20.phtml http://www.warpstock.eu/ Same for VMS in form of OpenVMS: http://en.wikipedia.org/wiki/OpenVMS http://h71000.www7.hp.com/index.html?jumpid=/go/openvms http://www.vmspython.org/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 19 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, 19 Apr 2011 07:06:09 +0200, Stefan Behnel wrote: > That's what makes the PEP feel so unfair to CPython developers, because > they are the ones who carry most of the burden of maintaining the stdlib in > the first place, and who will most likely continue to carry it, because > other implementations will continue to be occupied with their own core > development for another while or two. It is nice to read that other > implementations are contributing back patches that simplify their own reuse > of the stdlib code. However, that does not yet make them equal contributors > to the development and the maintenance of the stdlib, and is of very little > worth to the CPython project. It often even runs counter to the interest of > CPython itself. So, the PEP makes the burden worse in that it requires that someone who works on a module with a C accelerator must make sure that any existing Python version and the C version stay in sync, and that *anyone* who wants to introduce a new module into the stdlib must make sure it has a Python version if that is practical. IMO both of these are policies that make sense for CPython even aside from the existence of other implementations: Python is easier to read and understand, so where practical we should provide a Python version of any module in the stdlib, for the benefit of CPython users. It doesn't sound like a great burden to me, but I'm not really qualified to judge, since I don't generally work on C code. Also, could you expand on "It often even runs counter to the interest of CPython itself"? I'm not seeing that, unless you are talking about the parameter-binding micro-optimization, which I think we discourage these days anyway. > I think this social problem of the PEP can only be solved if the CPython > project stops doing the major share of the stdlib maintenance, thus freeing > its own developer capacities to focus on CPython related improvements and > optimisations, just like the other implementations currently do. I'm not > sure we want that at this point. Personally, I consider myself an stdlib maintainer: I only occasionally dabble in C code when fixing bugs that annoy me for some reason. I suppose that's why I'm one of the people backing this PEP. I think there are other CPython developers who might say the same thing. -- R. David Murray http://www.bitdance.com ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, 19 Apr 2011 10:37:41 -0400 "R. David Murray" wrote: > On Tue, 19 Apr 2011 07:06:09 +0200, Stefan Behnel wrote: > > That's what makes the PEP feel so unfair to CPython developers, because > > they are the ones who carry most of the burden of maintaining the stdlib in > > the first place, and who will most likely continue to carry it, because > > other implementations will continue to be occupied with their own core > > development for another while or two. It is nice to read that other > > implementations are contributing back patches that simplify their own reuse > > of the stdlib code. However, that does not yet make them equal contributors > > to the development and the maintenance of the stdlib, and is of very little > > worth to the CPython project. It often even runs counter to the interest of > > CPython itself. > > So, the PEP makes the burden worse in that it requires that someone who > works on a module with a C accelerator must make sure that any existing > Python version and the C version stay in sync, and that *anyone* who wants > to introduce a new module into the stdlib must make sure it has a Python > version if that is practical. IMO both of these are policies that make > sense for CPython even aside from the existence of other implementations: > Python is easier to read and understand, so where practical we should > provide a Python version of any module in the stdlib, for the benefit > of CPython users. > > It doesn't sound like a great burden to me, but I'm not really qualified > to judge, since I don't generally work on C code. I think it's ok. Our experience on the io module proves, I think, that's it's indeed useful to have a pure Python (pseudocode-like) implementation. 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, 19 Apr 2011 12:01:44 +0200, Stefan Behnel wrote: > A related question is: when other Python VM projects try to port a given C > module, would they actually invest the time to write a pure Python version > that may or may not run within acceptable performance bounds for them, or > would they prefer saving time by writing only a native implementation > directly for their VM for performance reasons? Maybe both, maybe not. If > they end up writing a native version after prototyping in Python, is the > prototype worth including in the shared stdlib, even if its performance is > completely unacceptable for everyone? Or, if they write a partial module > and implement another part of it natively, would the incomplete > implementation qualify as a valid addition to the shared stdlib? I would say yes, it is worth including. And even more worth including is any additional tests they develop to validate their implementation. > Implementing a 100% compatible and "fast enough" Python version of a module > is actually a rather time consuming task. I think we are expecting some > altruism here that is easily sacrificed for time constraints, in any of the > Python VM projects. CPython is just in the unlucky position of representing > the status-quo. Well, I don't think we are really expecting altruism. We're trying to leverage the work the community is doing, by drawing as much of the Python code and validation tests that get created into a common stdlib. If a module in the wild is being considered for inclusion in the stdlib, it will need to have a Python version if practical. Since we accept so few modules anyway (for good reason), I really don't see this as a big deal. And, there's always the practicality beats purity argument: if the PEP turns out to really get in the way of something everyone wants, then we can agree to an exception. -- R. David Murray http://www.bitdance.com ___ 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 399: Pure Python/C Accelerator Module Compatibiilty Requirements
On Tue, 19 Apr 2011 14:29:24 +0200, Maciej Fijalkowski wrote: > > Once this move is made/accepted, I would expect the other > > implementation to rapidly move away from their custom implementations > > of the stdlib and contribute to the shared code base and > > documentation. Yes, this places a burden on CPython, but in the long > > term in benefits *all* of the projects equally by simply having more > > active contributors. > > I would also like to point out that some valuable contributions were > made already by other implementations. When talking about stdlib, it's > mostly in the area of test suite, but not only in terms of "skip those > tests", but also improving test coverage and even fixing bugs. Unicode > fixes were prototyped on PyPy first and some PyPy optimizations were > ported to CPython (the original method cache patch came from Armin > Rigo as far as I remember). So it's not completely "Cpython's burden" > only. Yes, and you also need to keep in mind that several developers wear multiple hats, and contribute to CPython on a regular or semi-regular basis. It is also enlightening to look at the output of hg churn. The number of active CPython developers over the past year is not huge, and very few of them have spoken up in this thread. -- R. David Murray http://www.bitdance.com ___ 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] [Python-checkins] cpython (2.7): Fix a few hyphens in argparse.rst.
Hi, summary: Fix a few hyphens in argparse.rst. - :synopsis: Command-line option and argument parsing library. + :synopsis: Command-line option and argument-parsing library. I believe that change should be reverted. “argument parsing library” is a noun determined (qualified) by another noun itself determined by a noun, not by an adjective. - followed by zero or one command-line args. When parsing the command-line, if + followed by zero or one command-line args. When parsing the command line, if You changed “arg” to “argument” in one place but not throughout. I think it’s best to use only full words in the docs (and for names in code, as recommended by PEP 8 :). Regards ___ 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] Drop OS/2 and VMS support?
On Apr 19, 2011, at 10:36 AM, M.-A. Lemburg wrote: > Victor Stinner wrote: >> Hi, >> >> I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, >> our OS/2 maintainer, answered: >> http://mail.python.org/pipermail/python-dev/2010-April/099477.html >> >> Extract: << The 3.x branch needs quite a bit of work on OS/2 to >> deal with Unicode, as OS/2 was one of the earlier OSes with full >> multiple language support and IBM developed a unique API. I'm still >> struggling to come to terms with this, partly because I myself don't >> "need" it. >> >> >> So one year later, Python 3 does still not support OS/2. >> >> -- >> >> About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if >> Python 3 does work on VMS. I bet that it does just not compile :-) >> >> I don't know anyone using VMS or OS/2. >> >> -- >> >> There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait >> until someone work on these OSes to ensure that the test suite pass. But >> if nobody cares of these OSes and nobody wants to maintain them, it >> would be easier for the maintenance of the Python source code base to >> remove specific code. >> >> Well, not "remove" directly, but plan to remove it using the PEP 11 >> procedure (mark OS/2 and VMS as unsupported, and remove the code in >> Python 3.4). > > The Python core team is not really representative of the Python > community users, so I think this needs a different approach: > > Instead of simply deprecating OSes without notice to the general > Python community, how about doing a "call for support" for these > OSes ? > > If that doesn't turn up maintainers, then we can take the PEP 11 > route. Victor, if you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access. Doug ___ 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] Drop OS/2 and VMS support?
Doug Hellmann wrote: > > On Apr 19, 2011, at 10:36 AM, M.-A. Lemburg wrote: > >> Victor Stinner wrote: >>> Hi, >>> >>> I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, >>> our OS/2 maintainer, answered: >>> http://mail.python.org/pipermail/python-dev/2010-April/099477.html >>> >>> Extract: << The 3.x branch needs quite a bit of work on OS/2 to >>> deal with Unicode, as OS/2 was one of the earlier OSes with full >>> multiple language support and IBM developed a unique API. I'm still >>> struggling to come to terms with this, partly because I myself don't >>> "need" it. >> >>> >>> So one year later, Python 3 does still not support OS/2. >>> >>> -- >>> >>> About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if >>> Python 3 does work on VMS. I bet that it does just not compile :-) >>> >>> I don't know anyone using VMS or OS/2. >>> >>> -- >>> >>> There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait >>> until someone work on these OSes to ensure that the test suite pass. But >>> if nobody cares of these OSes and nobody wants to maintain them, it >>> would be easier for the maintenance of the Python source code base to >>> remove specific code. >>> >>> Well, not "remove" directly, but plan to remove it using the PEP 11 >>> procedure (mark OS/2 and VMS as unsupported, and remove the code in >>> Python 3.4). >> >> The Python core team is not really representative of the Python >> community users, so I think this needs a different approach: >> >> Instead of simply deprecating OSes without notice to the general >> Python community, how about doing a "call for support" for these >> OSes ? >> >> If that doesn't turn up maintainers, then we can take the PEP 11 >> route. > > Victor, if you want to post the "call for support" to Python Insider, let me > know off list and I will set you up with access. I can help with that if you like. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 19 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Drop OS/2 and VMS support?
Le mardi 19 avril 2011 à 15:20 -0400, Doug Hellmann a écrit : > > The Python core team is not really representative of the Python > > community users, so I think this needs a different approach: > > > > Instead of simply deprecating OSes without notice to the general > > Python community, how about doing a "call for support" for these > > OSes ? > > > > If that doesn't turn up maintainers, then we can take the PEP 11 > > route. > > Victor, if you want to post the "call for support" to Python Insider, > let me know off list and I will set you up with access. If we ask users if they want to keep OS/2 and VMS, I expect that at least someone would like to keep them. But it doesn't solve the maintenance problem: we need maintainers (developers), not users. If a "call for support" can help us to maintain these OSes, nice. But I don't want to touch these OSes (I want to do less work, not more work :-)), and so I don't want to write such call. If you feel concerned by this issue, contact Doug to write the call ;-) Victor ___ 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] Drop OS/2 and VMS support?
On Tue, 19 Apr 2011 15:20:13 -0400 Doug Hellmann wrote: > > Victor, if you want to post the "call for support" to Python Insider, let me > know off list and I will set you up with access. Doesn't it have more chances of succeeding if posted to comp.lang.python, simply? 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] Drop OS/2 and VMS support?
> Well, not "remove" directly, but plan to remove it using the PEP 11 > procedure (mark OS/2 and VMS as unsupported, and remove the code in > Python 3.4). I think the PEP 11 procedure is just right for this. It *is* a call for maintainers, so if any user is interested in ongoing support, they should step forward. Having then also blog posts about these pending deprecations sounds fine to me - also adding them to the 3.2.x release pages would be appropriate (IMO). It's important that we give users due notice, but lacking any actual contribution, we should also be able to remove the code eventually. So please go ahead and add them to PEP 11. Regards, Martin ___ 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
