[Python-Dev] ABI stability between bugfix versions?
Hello, To fix the crash in http://bugs.python.org/issue13992, I have to change the definition of the Py_TRASHCAN_SAFE_BEGIN and Py_TRASHCAN_SAFE_END macros in a way that makes them stop rely on global variables. Despite being undocumented, these two macros are used in a couple of third-party extension modules (*) such as greenlet and py-judy. This means that such an extension compiled for 2.7.3 wouldn't work with 2.7.4, and vice-versa. Is there something we can do to alleviate the issue? Add a note in the release notes? Regards Antoine. (*) http://code.google.com/codesearch#search&q=Py_TRASHCAN_SAFE_BEGIN -- Software development and contracting: http://pro.pitrou.net ___ 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] Coverity scan
Hello everybody, two weeks ago Stefan Krah asked for a current Coverity scan report. Coverity has updated us to a new version with a new workflow. Before the update Coverity pulled the code from our version control system. However the latest version doesn't work that way. The code must be compiled with the Coverity tool chain, published to a public web server and then downloaded by Coverity. http://mail.python.org/pipermail/python-committers/2012-August/002134.html It's easy, doesn't take much effort and can easily be automated, but somebody has to do it. The process should also be placed on the Python infrastructure and I don't have access. Secondly somebody has to contact Coverity to apply for an upload account. I tried my user account without success. It be nice if we get Coverity scans up and running this week to check the upcoming release candidate for issues. Christian ___ 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] Coverity scan
On Mon, 03 Sep 2012 15:59:59 +0200 Christian Heimes wrote: > > It's easy, doesn't take much effort and can easily be automated, but > somebody has to do it. The process should also be placed on the Python > infrastructure and I don't have access. Secondly somebody has to contact > Coverity to apply for an upload account. I tried my user account without > success. You could ask [email protected] for an account on an existing machine (dinsdale perhaps, it looks much less loaded now that some services have been migrated). Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ 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] Coverity scan
Am 03.09.2012 16:27, schrieb Antoine Pitrou: > You could ask [email protected] for an account on an existing > machine (dinsdale perhaps, it looks much less loaded now that some > services have been migrated). Thanks Antoine! I've contacted the infrastructure team. Christian ___ 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] Should 2to3 convert Exceptions from
On Sun, Sep 2, 2012 at 11:26 PM, Lennart Regebro wrote: > Switched from python-dev to python-porting. > > On Sun, Sep 2, 2012 at 9:48 PM, anatoly techtonik wrote: >> I work offline from remote location about 2000m above the sea level. There >> is no internet connection here, so I can not use tracker online. I need a >> Python editor here, and I have Spyder checkout. The problem is that my >> installation has only Python3. I've tried using 2to3 from setup.py >> (attached), but it fails when I execute: >> >> $ sudo python3 setup.py install >> >> stderr.log and stdout.log are attached. Is it the intended behavior? >> It is also hard find "Porting Python 2 Code to Python 3" article, because it >> is not referenced from "Porting to Python 3.x" chapters. > > 2to3 has not been run on the code that gives you errors. The traceback > seems incomplete, and gives no indication of where in the install you > get the errors. From the stdout it seems like it just installs the > code without using 2to3. > > The only idea I have at this moment i sto make sure that the build > directories are empty. Removing build/ directory helped indeed. I wonder why it doesn't remove them automatically? IIRC there is no incremental build support. -- 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] ABI stability between bugfix versions?
Am 03.09.2012 12:11, schrieb Antoine Pitrou: > Despite being undocumented, these two macros are used in a couple of > third-party extension modules (*) such as greenlet and py-judy. This > means that such an extension compiled for 2.7.3 wouldn't work with > 2.7.4, and vice-versa. Is there something we can do to alleviate the > issue? Add a note in the release notes? I think breaking existing extension modules in a bugfix release is really not acceptable. I also think that the breakage can be reduced by keeping the global variable. There would then be two counters: the global used by old modules, the per-thread counter used by recompiled modules. I believe this would require separate versions of the helper functions also. In the worst case, this could cause the nesting to go twice as deep, which is not a problem, since the nesting is only 50, anyway. The question also is about the other direction: modules compiled for 2.7.4 that are run on 2.7.3. I think this would be more problematic in your patch, since the code would just access fields in the thread state which aren't there. If the helper functions are called differently, the extension would fail to load, which IMO is the better reaction. 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
Re: [Python-Dev] Should 2to3 convert Exceptions from
On Mon, Sep 3, 2012 at 10:18 PM, anatoly techtonik wrote: > On Sun, Sep 2, 2012 at 11:26 PM, Lennart Regebro wrote: >> Switched from python-dev to python-porting. >> >> On Sun, Sep 2, 2012 at 9:48 PM, anatoly techtonik >> wrote: >>> I work offline from remote location about 2000m above the sea level. There >>> is no internet connection here, so I can not use tracker online. I need a >>> Python editor here, and I have Spyder checkout. The problem is that my >>> installation has only Python3. I've tried using 2to3 from setup.py >>> (attached), but it fails when I execute: >>> >>> $ sudo python3 setup.py install >>> >>> stderr.log and stdout.log are attached. Is it the intended behavior? >>> It is also hard find "Porting Python 2 Code to Python 3" article, because it >>> is not referenced from "Porting to Python 3.x" chapters. >> >> 2to3 has not been run on the code that gives you errors. The traceback >> seems incomplete, and gives no indication of where in the install you >> get the errors. From the stdout it seems like it just installs the >> code without using 2to3. >> >> The only idea I have at this moment i sto make sure that the build >> directories are empty. > > Removing build/ directory helped indeed. I wonder why it doesn't > remove them automatically? IIRC there is no incremental build support. It doesn't remove them to avoid having to recompile everything everytime you run it. But it compares timestamps, so if you run build, and then add the 2to3 support, it will see that all the py-files are up to date, and not run 2to3 on them. //Lennart ___ 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] ABI stability between bugfix versions?
On Mon, 03 Sep 2012 22:37:31 +0200 "Martin v. Löwis" wrote: > Am 03.09.2012 12:11, schrieb Antoine Pitrou: > > Despite being undocumented, these two macros are used in a couple of > > third-party extension modules (*) such as greenlet and py-judy. This > > means that such an extension compiled for 2.7.3 wouldn't work with > > 2.7.4, and vice-versa. Is there something we can do to alleviate the > > issue? Add a note in the release notes? > > I think breaking existing extension modules in a bugfix release is > really not acceptable. > > I also think that the breakage can be reduced by keeping the global > variable. There would then be two counters: the global used by > old modules, the per-thread counter used by recompiled modules. > I believe this would require separate versions of the helper functions > also. Indeed. That sounds workable, despite the added complexity. > The question also is about the other direction: modules compiled > for 2.7.4 that are run on 2.7.3. I think this would be more problematic > in your patch, since the code would just access fields in the thread > state which aren't there. If the helper functions are called > differently, the extension would fail to load, which IMO is the better > reaction. Right, that's a better behaviour than crashing. Thank you, 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
