Re: [Python-Dev] [issue1644818] Allow importing built-in submodules
> But in my current position and with "I-do-software-developement-too", > you are just pissing me off for not fixing a bug in your program with a 10 > lines long patch written by someone else 3 years ago. Unfortunately, it is not obvious to me that the patch is correct, so I couldn't check it in as-is. The review would probably take an hour or two. > Something that should take 5 minutes, probably the time we both lost by > writing our respective emails. Or give commit access, I'll do it for > you. Thanks, no. One possible side effect of the five reviews might be that we could build trust in the reviewer not just to check in everything, but apply careful review before. 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] [issue1644818] Allow importing built-in submodules
At 1261181806 time_t, "Martin v. Löwis" wrote: > Only if some committer finds time for it, which is *really* scarce. > If you want to push that issue, I promise to review it after you have > reviewed five other patches. Well, that's disapointing. I work on several other free software projects, and my time is really scarce too. I understand blackmailing me to close a bug can be seen as a nice game. Honestly, if I had more time to get involve in that area, I'll take it as a game and would do it with pleasure. But in my current position and with "I-do-software-developement-too", you are just pissing me off for not fixing a bug in your program with a 10 lines long patch written by someone else 3 years ago. Something that should take 5 minutes, probably the time we both lost by writing our respective emails. Or give commit access, I'll do it for you. Anyway, thanks. Cheers, -- Julien Danjou // ᐰhttp://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // This is the end of my signature. signature.asc Description: Digital signature ___ 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] Renewal of the 1-for-5 offer (was: [issue1644818] Allow importing built-in submodules)
On Sat, 19 Dec 2009 01:16:46 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote: > Only if some committer finds time for it, which is *really* scarce. > If you want to push that issue, I promise to review it after you have > reviewed five other patches. As a general note, I'm willing to make the same deal. Anyone who has a patch they are championing, if you will review some other patches for us, I'll see if I can get the patch you are interested in committed. We have a lot of patches in the tracker that only the submitter has looked at/tested, or which lack tests or doc updates, and so they just sit there... (By the way, Julian, if you had done a review of the patch in question (tested it, etc, and reported your results) progress on the bug might have just started happening. This is how it often works; although there's no guarantee of course.) I'd also like to point out that IMO the idea behind the one-for-five offer is to leverage the "I have an itch to scratch" energy to the benefit of all and, just as important (and as Martin already pointed out), perhaps set some new people on the path to becoming committers. -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ 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] [issue1644818] Allow importing built-in submodules
On Dec 19, 2009, at 5:29 AM, Julien Danjou wrote: > Well, that's disapointing. I work on several other free software > projects, and my time is really scarce too. > > I understand blackmailing me to close a bug can be seen as a nice game. > Honestly, if I had more time to get involve in that area, I'll > take it as a game and would do it with pleasure. > > But in my current position and with "I-do-software-developement-too", > you are just pissing me off for not fixing a bug in your program with a 10 > lines long patch written by someone else 3 years ago. > > Something that should take 5 minutes, probably the time we both lost by > writing our respective emails. Or give commit access, I'll do it for > you. I think you're missing the point here. This one particular patch is 10 lines long, but the problem is that there are thousands of patches in the Python tracker, many of which are buggy or incorrect, all of which need to be reviewed. All of which *are* being reviewed, as people have time. Nothing is particularly special about your patch. In other words, Martin is asking you to review only 5 patches, but you're asking him to review tens of thousands. I think the 5-for-1 deal is a great idea, because it takes peoples' impatience and turns it into a resource to deal with other peoples' impatience :). ___ 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] [issue1644818] Allow importing built-in submodules
Martin v. Löwis wrote: >> But in my current position and with "I-do-software-developement-too", >> you are just pissing me off for not fixing a bug in your program with a 10 >> lines long patch written by someone else 3 years ago. > > Unfortunately, it is not obvious to me that the patch is correct, so I > couldn't check it in as-is. The review would probably take an hour or > two. I definitely plan on spending a lot more than 5 minutes on it - in particular, I want to see if I can find a way to avoid adding yet-more-test-code to the main binary. (Probably not, given the nature of the feature we're trying to test in this case, but I'm still going to try). 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
[Python-Dev] Providing support files to assist 3.x extension authors
Hello, When I ported gmpy (Python to GMP multiple precision library) to Python 3.x, I began to use PyLong_AsLongAndOverflow frequently. I found the code to slightly faster and cleaner than using PyLong_AsLong and checking for overflow. I looked at making PyLong_AsLongAndOverflow available to Python 2.x. http://bugs.python.org/issue7528 includes a patch that adds PyLong_AsLongAndOverflow to Python 2.7. I also included a file (py3intcompat.c) that can be included with an extension's source code and provides PyLong_AsLongAndOverflow to earlier versions of Python 2.x. In the bug report, I suggested that py3intcompat.c could be included in the Misc directory and be made available to extension authors. This follows the precedent of pymemcompat.h. But there may be more "compatibility" files that could benefit extension authors. Mark Dickinson suggested that I bring the topic on python-dev. Several questions come to mind: 1) Is it reasonable to provide backward compatibility files (either as .h or .c) to provide support to new API calls to extension authors? 2) If yes, should they be included with the Python source or distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki page) 3) If not, and extension authors can create their own compatibility files, are there any specific attribution or copyright messages that must be included? (I assuming the compatibility was done by extracting the code for the new API and tweaking it to run on older versions of Python.) Thanks in advance for your attention, Case Van Horsen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Providing support files to assist 3.x extension authors
Case Vanhorsen wrote: > Hello, > > When I ported gmpy (Python to GMP multiple precision library) to > Python 3.x, I began to use PyLong_AsLongAndOverflow frequently. I > found the code to slightly faster and cleaner than using PyLong_AsLong > and checking for overflow. I looked at making PyLong_AsLongAndOverflow > available to Python 2.x. http://bugs.python.org/issue7528 includes a > patch that adds PyLong_AsLongAndOverflow to Python 2.7. > > I also included a file (py3intcompat.c) that can be included with an > extension's source code and provides PyLong_AsLongAndOverflow to > earlier versions of Python 2.x. In the bug report, I suggested that > py3intcompat.c could be included in the Misc directory and be made > available to extension authors. This follows the precedent of > pymemcompat.h. But there may be more "compatibility" files that could > benefit extension authors. Mark Dickinson suggested that I bring the > topic on python-dev. > > Several questions come to mind: > > 1) Is it reasonable to provide backward compatibility files (either as > .h or .c) to provide support to new API calls to extension authors? As a minor terminology nit, I'd call these "forward compatibility" files - they're backports of Py3k interfaces to 2.x to make it easier to write modules that will compile with both 2.x and 3.x. > 2) If yes, should they be included with the Python source or > distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki > page) That depends - if we're only targeting 2.7, then including the compatibility files directly in the Python source would be fine. But for a solution to be usable with extensions intended for use with 2.6 (or even 2.5) it would be necessary to distribute the forward compatibility files separately. > 3) If not, and extension authors can create their own compatibility > files, are there any specific attribution or copyright messages that > must be included? (I assuming the compatibility was done by extracting > the code for the new API and tweaking it to run on older versions of > Python.) For code extracted from the Python source, the PSF licenses would still apply. 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
