Re: [Python-Dev] Would like to contribute to Core Python Comunity on the Project Idea
Hi Nitin, Thanks for your interest in CPython for Google Summer of Code. We are still getting our ducks in a row, and mentor organizations haven't been finalized yet (the official mentor list will go out on February 24th). Can you check back in then? In the meantime, I recommend: 1. Joining http://pythonmentors.com/ 2. Reading through the developers guide: http://docs.python.org/devguide/ 3. Picking and working on a ticket to get used to the workflow: http://bugs.python.org/ Regards, -Jessica On Sat, Feb 15, 2014 at 12:23 AM, Nitin Agarwal wrote: > Hi, > > Here, its Nitin Agarwal, an open source software developer and enthusiast. > Currently, I am pursuing Computer Science and Engineering at International > Institute of Information Technology, INDIA. I had an experience working > with > the open source organisations and development of open source software. > > > You can have a look at my github profile.[1] My first priority > programming languages > include GNU C/C++ and Python. I have been using these languages for the > Coding, > Programming challenges, Application development and contributing to open > source > software. Apart from this, I am also aware of version control systems > git/github, SVN, > bazaar and other web technologies like Javascript, Jinja templates, HTML, > CSS too. > I am ambititous person eager to learn other technologies when in need > while working. > You can have a look at my Wikipedia profile.[2] > My interests include Programming Languages, open source software > development, > networking concepts and system administration tasks. > > > While looking at the Project Ideas proposed by the mentors and developers > of the Python > Community, I found the Email Projects working to work for support of RFC > 6532 in the > email package and support of RFC 6531 in the smtplib and/or smtpd. > > I am willing to work on this project ideas as a prospective student in the > upcoming > Google Summer of Code 2014. I would like to discuss with the mentors more > about > the project in detail and would like to start off contributing to the > project early enough > so as to make a strong proposal for Gsoc 2014. > > > > *Nitin Agarwal* > > > [1] https://github.com/NitinAgarwal > [2] https://en.wikipedia.org/wiki/User:Nitinagarwal3006 > [3] IRC handle : nitinagarwal3006 > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jessica.mckellar%40gmail.com > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Would like to contribute to Core Python Comunity on the Project Idea
Thanks for your reply. I have joined on the pythonmentors.com and gone through the developer guide. Yes, I am going through the present bugs to resolve some of them. Could you Please reply as soon as you get the mentors allocated for the Possible email projects being proposed for Gsoc 2014. It will help me discuss the project idea with the mentor so as to make a good proposal and get a great work done in the 3 months of upcoming Summer of Code. *Nitin Agarwal* On Sat, Feb 15, 2014 at 5:52 PM, Jessica McKellar < [email protected]> wrote: > Hi Nitin, > > Thanks for your interest in CPython for Google Summer of Code. > > We are still getting our ducks in a row, and mentor organizations haven't > been finalized yet (the official mentor list will go out on February 24th). > Can you check back in then? > > In the meantime, I recommend: > > 1. Joining http://pythonmentors.com/ > 2. Reading through the developers guide: http://docs.python.org/devguide/ > 3. Picking and working on a ticket to get used to the workflow: > http://bugs.python.org/ > > Regards, > -Jessica > > > > > > On Sat, Feb 15, 2014 at 12:23 AM, Nitin Agarwal < > [email protected]> wrote: > >> Hi, >> >> Here, its Nitin Agarwal, an open source software developer and >> enthusiast. >> Currently, I am pursuing Computer Science and Engineering at International >> Institute of Information Technology, INDIA. I had an experience working >> with >> the open source organisations and development of open source software. >> >> >> You can have a look at my github profile.[1] My first priority >> programming languages >> include GNU C/C++ and Python. I have been using these languages for the >> Coding, >> Programming challenges, Application development and contributing to open >> source >> software. Apart from this, I am also aware of version control systems >> git/github, SVN, >> bazaar and other web technologies like Javascript, Jinja templates, HTML, >> CSS too. >> I am ambititous person eager to learn other technologies when in need >> while working. >> You can have a look at my Wikipedia profile.[2] >> My interests include Programming Languages, open source software >> development, >> networking concepts and system administration tasks. >> >> >> While looking at the Project Ideas proposed by the mentors and developers >> of the Python >> Community, I found the Email Projects working to work for support of RFC >> 6532 in the >> email package and support of RFC 6531 in the smtplib and/or smtpd. >> >> I am willing to work on this project ideas as a prospective student in >> the upcoming >> Google Summer of Code 2014. I would like to discuss with the mentors more >> about >> the project in detail and would like to start off contributing to the >> project early enough >> so as to make a strong proposal for Gsoc 2014. >> >> >> >> *Nitin Agarwal* >> >> >> [1] https://github.com/NitinAgarwal >> [2] https://en.wikipedia.org/wiki/User:Nitinagarwal3006 >> [3] IRC handle : nitinagarwal3006 >> >> >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/jessica.mckellar%40gmail.com >> >> > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add Py_REPLACE and Py_XREPLACE macros
29.01.14 20:24, Serhiy Storchaka написав(ла): The Py_CLEAR macros is used as safe alternative for following unsafe idiomatic code: Py_XDECREF(ptr); ptr = NULL; But other unsafe idiomatic code is widely used in the sources: Py_XDECREF(ptr); ptr = new_value; Every occurrence of such code is potential bug for same reasons as for Py_CLEAR. It was offered [1] to introduce new macros Py_REPLACE and Py_XREPLACE for safe replace with Py_DECREF and Py_XDECREF respectively. Automatically generated patch contains about 50 replaces [2]. [1] http://bugs.python.org/issue16447 [2] http://bugs.python.org/issue20440 There are objections to these patches. Raymond against backporting the patch unless some known bugs are being fixed [1]. But it fixes at least one bug that caused a crash. And I suspect that there may be other bugs, just we still have no reproducers. Even if we don't know how to reproduce the bug, the current code looks obviously wrong. Also porting the patch will make the sync easier. Note that the patches were automatically generated, which reduces the possibility of errors. I just slightly corrected formatting, remove unused variables and fixed one error. Martin's objections are that the macros do add to the learning curve and his expects that Py_REPLACE(op, op2) does an INCREF on op2, but it does not [2]. Antoine's original Py_(X)SETREF macros did INCREF and seems this was one of their flaw, because in most cases INCREF is not needed. Alternative names Py_(X)ASSIGN were suggested to break connotation of an INCREF [3]. As for learning curve, I think that it would be better to have standard macros for code that can be written (and often are written) incorrectly. And even already correct code can be written with these macros in more short and clear way [4]. Greg shared Martin's expectation and suggested to revive this thread. [1] http://bugs.python.org/issue20440#msg209701 [2] http://bugs.python.org/issue20440#msg209894 [3] http://bugs.python.org/issue20440#msg210447 [4] http://bugs.python.org/issue3081#msg102645 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Using more specific methods in Python unit tests
Many Python tests were written a very long time before the unittest, using simple asserts. Then, when they have been ported to the unittest, asserts were replaced with the assert_ method and then with assertTrue. The unittest has a number of other methods to check for and report failure, from assertEqual, to more specific assertIs, assertIn, assertIsInstance, etc, added in 2.7. New methods provide better reporting in case of failure. I wrote a large patch which modifies the tests to use more specific methods [1]. Because it is too large, it was divided into many smaller patches, and separate issues were opened for them. At the moment the major part of the original patch has already been committed. Many thanks to Ezio for making a review for the majority of the issues. Some changes have been made by other people in unrelated issues. Although Raymond approved a patch for test_bigmem [2], his expressed the insistent recommendation not to do this. So I stop committing new reviewed patches. Terry recommended to discuss this in Python-Dev. What are your thoughts? [1] http://bugs.python.org/issue16510 [2] http://bugs.python.org/issue20547 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pickling of Enums
How Enum items should be pickled, by value or by name? I think that Enum will be used to collect system-depending constants, so the value of AddressFamily.AF_UNIX can be 1 on one platform and 2 on other. If pickle enums by value, then pickled AddressFamily.AF_INET on on platform can be unpickled as AddressFamily.AF_UNIX on other platform. This looks weird and contrary to the nature of enums. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using more specific methods in Python unit tests
On Sat, Feb 15, 2014, at 10:12 AM, Serhiy Storchaka wrote: > Many Python tests were written a very long time before the unittest, > using simple asserts. Then, when they have been ported to the unittest, > asserts were replaced with the assert_ method and then with assertTrue. > The unittest has a number of other methods to check for and report > failure, from assertEqual, to more specific assertIs, assertIn, > assertIsInstance, etc, added in 2.7. New methods provide better > reporting in case of failure. > > I wrote a large patch which modifies the tests to use more specific > methods [1]. Because it is too large, it was divided into many smaller > patches, and separate issues were opened for them. At the moment the > major part of the original patch has already been committed. Many thanks > to Ezio for making a review for the majority of the issues. Some changes > have been made by other people in unrelated issues. > > Although Raymond approved a patch for test_bigmem [2], his expressed the > insistent recommendation not to do this. So I stop committing new > reviewed patches. Terry recommended to discuss this in Python-Dev. What > are your thoughts? I tend to agree with Raymond. I think such changes are very welcome when the module or tests are otherwise being changed, but on their on constitute unnecessary churn. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling of Enums
On Sat, 15 Feb 2014 21:01:36 +0200 Serhiy Storchaka wrote: > How Enum items should be pickled, by value or by name? > > I think that Enum will be used to collect system-depending constants, so > the value of AddressFamily.AF_UNIX can be 1 on one platform and 2 on > other. If pickle enums by value, then pickled AddressFamily.AF_INET on > on platform can be unpickled as AddressFamily.AF_UNIX on other platform. > This looks weird and contrary to the nature of enums. I agree with you, they should be pickled by name. An enum is a kind of global in this regard. (but of course, before AF_UNIX was an enum it was pickled by value) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using more specific methods in Python unit tests
On 2/15/2014 1:12 PM, Serhiy Storchaka wrote: Many Python tests were written a very long time before the unittest, using simple asserts. Then, when they have been ported to the unittest, asserts were replaced with the assert_ method and then with assertTrue. The unittest has a number of other methods to check for and report failure, from assertEqual, to more specific assertIs, assertIn, assertIsInstance, etc, added in 2.7. New methods provide better reporting in case of failure. Failure of assertTrue reports 'False is not true'. I wrote a large patch which modifies the tests to use more specific methods [1]. Because it is too large, it was divided into many smaller patches, and separate issues were opened for them. At the moment the major part of the original patch has already been committed. Many thanks to Ezio for making a review for the majority of the issues. Some changes have been made by other people in unrelated issues. Although Raymond approved a patch for test_bigmem [2], his expressed the insistent recommendation not to do this. So I stop committing new reviewed patches. Terry recommended to discuss this in Python-Dev. What are your thoughts? [1] http://bugs.python.org/issue16510 [2] http://bugs.python.org/issue20547 After thinking about Raymond's objections and checking http://docs.python.org/3/library/unittest.html#test-cases and noting Ezio's explicit approval and others tacit approval (by lack of objection), I think you should continue and finish. The reasons for not making making style changes in public stdlib modules are that we want people to import and use them, have promised stability absent notice otherwise, and because it is reasonably possible to make unintended semantic changes that might pass unnoticed by incomplete tests. The case is different on all counts for test.text_xyz modules. They are private application modules, not to be imported (except to run them), and subject to change without notice. Nearly all the changes proposed are from assertTrue to various specialized assertXs with documented equivalences to assertTrue. I presume you made the 1-to-1 replacements with a script using capturing regexes, with a check for false replacements such as might occasionally happen due to an operator being inside a string. If we are ever to make the replacements, doing so mechanically and in bulk is easier and safer than doing them one at a time by hand. This includes reviewing. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4
On 13 February 2014 20:58, Paul Moore wrote: > On 13 February 2014 20:54, Donald Stufft wrote: >> >> On Feb 13, 2014, at 3:53 PM, Paul Moore wrote: >> >>> Can someone please take a look at http://bugs.python.org/issue20621 >>> for me? It appears that there is a significant problem with zipimport >>> in 3.3.4. It's causing breakage in virtualenv but I've isolated the >>> issue to what I think is Python itself. >>> >>> Basically, until this bug is fixed, virtualenv won't work on Windows >>> with Python 3.3.4, as far as I can tell. >> >> Does it affect 3.4? > > Just checked that. No, it's not an issue in 3.4rc0. Nor is it in > 3.3.3, so it's a regression in the 3.3 series only. OK, this appears to be a serious regression that breaks virtualenv. Steve Dower suggested a workaround on the tracker, but I don't think that can be made to work in the case of virtualenv (for reasons not worth explaining now, ask me if you want the details though). Given where we are, what is the way forward here? I'm not entirely sure what I should be saying to the user who reported the bug in virtualenv. I think I'll recommend downgrading to 3.3.3 for now, but it would be good to be able to give an idea of what the longer term solution is likely to be. Thanks Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using more specific methods in Python unit tests
In article <[email protected]>, Benjamin Peterson wrote: > On Sat, Feb 15, 2014, at 10:12 AM, Serhiy Storchaka wrote: > > Although Raymond approved a patch for test_bigmem [2], his expressed the > > insistent recommendation not to do this. So I stop committing new > > reviewed patches. Terry recommended to discuss this in Python-Dev. What > > are your thoughts? > I tend to agree with Raymond. I think such changes are very welcome when > the module or tests are otherwise being changed, but on their on > constitute unnecessary churn. +1 Integrity of the test suite and minimizing code churn top any benefits of more specific messages on failures. The expectation is that most tests will never fail so their changed messages will never be seen. For the rare cases when a test does fail, quite often the test was written in a way that will require examination of the code to understand exactly what the test case was intending to test and why it failed. Having a more specific exception message wouldn't help for many tests without further modifications; the key point is to know that the test failed. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add Py_REPLACE and Py_XREPLACE macros
On 16 February 2014 02:52, Serhiy Storchaka wrote: > There are objections to these patches. Raymond against backporting the patch > unless some known bugs are being fixed [1]. But it fixes at least one bug > that caused a crash. And I suspect that there may be other bugs, just we > still have no reproducers. Even if we don't know how to reproduce the bug, > the current code looks obviously wrong. Also porting the patch will make the > sync easier. Note that the patches were automatically generated, which > reduces the possibility of errors. I just slightly corrected formatting, > remove unused variables and fixed one error. It's also likely than many of these crashes could only be reproduced through incorrect usage of the C API. Py_CLEAR/Py_XCLEAR was relatively simple, as there's only one pointer involved. As Martin noted, Py_REPLACE is more complex, as there's the question of whether or not the refcount for the RHS gets incremented. Rather than using a completely different name, perhaps we can leverage "Py_CLEAR" to make it more obvious that this operation is "like Py_CLEAR and for the same reason, just setting the pointer to something other than NULL". For example: Py_CLEAR_AND_SET Py_XCLEAR_AND_SET Such that Py_CLEAR and Py_XCLEAR are equivalent to: Py_CLEAR_AND_SET(target, NULL); Py_XCLEAR_AND_SET(target, NULL); (Note that existing occurrences of SET in C API macros like PyList_SET_ITEM and PyTuple_SET_ITEM also assume that any required reference count adjustments are handled externally). While the name does suggest the macro will expand to: Py_CLEAR(target); target = value; which isn't quite accurate, it's close enough that people should still be able to understand what the operation does. Explicitly pointing out in that docs that Py_CLEAR(target) is functionally equivalent to Py_CLEAR_AND_SET(target, NULL) should help correct the misapprehension. On the question of updating 3.4+ only vs also updating 3.3, I'm inclined towards fixing it systematically in all currently supported branches, as it's a low risk mechanical change. On the other hand, we still have other crash bugs with known reproducers (in Lib/test/crashers), so I'm also OK with leaving 3.3 alone. (Assuming we can agree on a name, I definitely think it's worth asking Larry for permission to make the late C API addition for 3.4, though) Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using more specific methods in Python unit tests
On 16 February 2014 09:20, Ned Deily wrote: > In article > <[email protected]>, > Benjamin Peterson wrote: >> On Sat, Feb 15, 2014, at 10:12 AM, Serhiy Storchaka wrote: >> > Although Raymond approved a patch for test_bigmem [2], his expressed the >> > insistent recommendation not to do this. So I stop committing new >> > reviewed patches. Terry recommended to discuss this in Python-Dev. What >> > are your thoughts? >> I tend to agree with Raymond. I think such changes are very welcome when >> the module or tests are otherwise being changed, but on their on >> constitute unnecessary churn. > > +1 > > Integrity of the test suite and minimizing code churn top any benefits > of more specific messages on failures. The expectation is that most > tests will never fail so their changed messages will never be seen. For > the rare cases when a test does fail, quite often the test was written > in a way that will require examination of the code to understand exactly > what the test case was intending to test and why it failed. Having a > more specific exception message wouldn't help for many tests without > further modifications; the key point is to know that the test failed. Right, there are a few key problems with large scale style changes to the test suite: 1. The worst case scenario is where we subtly change a test so that it is no longer testing what it is supposed to be testing, allowing the future introduction of an undetected regression. This isn't particularly *likely*, but a serious problem if it happens. 2. If there are pending patches for that module that include new tests, then the style change may cause the patches to no longer apply cleanly, require rework of bug fix and new feature patches to accommodate the style change. 3. Merges between branches may become more complicated (for reasons similar to 2), unless the style change is also applied to the maintenance branches (which is problematic due to 1). The practical benefits of this kind of change in the test suite are also highly dubious, because they *only help if the test fails at some point in the future*. At that point, whoever caused the test to fail will switch into debugging mode, and a couple of relevant points apply: * the cause of the problem may be immediately obvious anyway, since it's likely in whatever code they just changed * if they need more information, then they can refactor the failing test to use richer (and perhaps additional) assertions as part of the debugging exercise Now, debugging a failing test isn't a skill most programming courses teach, so it may be worth our while to actually provide some pointers on doing so effectively in the devguide (including a note about checking that the failing test is using rich assertions and potentially updating it if it isn't), but the general policy against large scale changes to take advantage of new features still applies to the test suite just as much as it does to the rest of the standard library. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
