[Python-Dev] Bug in PyErr_WriteUnraisable ?
I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer. We are embedding Python 2.5 and a string instance is raised using PyThreadState_SetAsyncExc. I can fix that in my code, by raising an appropiate exception instance, but I think PyErr_WriteUnraisable lacks some checks. -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES ___ 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] Embedded Python:: C/Python: Is Py_Finalize() necessary between embedded function calls?
Hi, I am developing an application where I have Python embedded in C
functions using the C/Python API to execute commands. My question stems
from my need to preserve a PyObject to pass between these Python
embedded C functions. My question is: do I have to call Py_Finalize() at
the end of each Python embedded C function?
The abstract structure of my code looks like this:
PyObject *po;
main() {
po = py_function_1();
// some C code in the middle here...
po = py_function_2(po);
// some more C code here...
}
In my implementation of py_function_1 and py_function_2 do I have to
call Py_Initialize() and Py_Finalize at the beginning and end of each of
the two functions? Or can I just call Py_Initialize at the beginning of
py_function_1 and then call Py_Finalize() at the end of py_function_2?
Thank You.
SP
___
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] Embedded Python:: C/Python: Is Py_Finalize() necessary between embedded function calls?
On Fri, Feb 23, 2007 at 04:24:19AM -0800, Sydney Pang wrote: do I have to call Py_Finalize() at the end of each Python embedded C function? As far I understand you only need to call Py_Initialize() and Py_Finalize() once per every embedded interpreter, not for an every function. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Bug in PyErr_WriteUnraisable ?
On 2/22/07, Gabriel Becedillas [EMAIL PROTECTED] wrote: I'd hit an access violation inside PyErr_WriteUnraisable when a non-exception instance was raised. The call to PyExceptionClass_Name with a non-exception instance is yielding an invalid pointer. We are embedding Python 2.5 and a string instance is raised using PyThreadState_SetAsyncExc. I can fix that in my code, by raising an appropiate exception instance, but I think PyErr_WriteUnraisable lacks some checks. Please use the the bug tracker at http://sourceforge.net/tracker/?group_id=5470atid=105470 to report issues with Python. -Brett -- Gabriel Becedillas Developer CORE SECURITY TECHNOLOGIES ___ 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/brett%40python.org ___ 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] dinner at Standard in Dallas
I'm organizing a trip to Standard in downtown Dallas for dinner tonight (Sunday night). It's about a 10 minute cab ride to Standard. We can share cabs and get there without too much trouble. The restaurant is on the expensive side. I'm thinking we should leave from the hotal around 6:30pm. http://www.standarddallas.com/ http://restaurants.dallasobserver.com/search/restaurants.php?oid=27399 A large group of us went for dinner last year and had a great time. The food was excellent, short ribs and mashed potatoes with truffles stand out in my mind. They also serve a tangerita cocktail--margerita made with Tang--that was memorable. Let me know if you'd like to come and I'll make reservations and arrange for cabs. Jeremy [Apologies if you get two copies of this message. The first one looks like it got lost or stuck.] ___ 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] Python-3000 upgrade path
I'm sending this to python-dev instead of python-3000 for two reasons: It's not about features to be added to Python 3.0, and it's not really about 3.0at all -- it's about 2.6 and later. It's about how we get Python 2.x to 3.0, and howmuch of 3.0we put into 2.6 and later. So here at PyCon, Guido did his usual talk about Py3K and how it's going to look. He also covered the tool he's writing to do the necessary syntactic translations, and short bits about how to write code to accommodate the other changes. One thing Guido didn't cover -- because it isn't his area of expertise and (correctly) expects others to step up and do it -- is the upgrade path for third party Python applications and libraries. I happen to care a lot about that, and so do a few other core Python developers, and we *will* make it happen in the smoothest way possible. We could use some community guidance on this, though. Here's my current thinking on the subject (and I talked about this with a couple of different people at the conference and in email): 1) Anything we can backport from Python 3.0 to Python 2.6 without breaking existing code, will be backported. So far, this means all the new features. 2) A few of the things going away in 3.0 will be warned about in 2.6 by default: things that have had better alternative for ages and are generally bad: backticks and input() are the only ones that come to mind right now. 3) The rest of the things that will change or go away in 3.0 *and* have alternatives in 2.6 will be warned about optionally. Neal is rewriting the warnings module to C, which should speed up warning generation a lot, and if necessary we'll use a global 'warn-for-py3k' flag to reduce the overhead for these warnings to the absolute minimum. 4) The new features of 3.0 that we can't backport (things changing semantics, instead of being added or going away) will be made available in 2.6 (as much as possible), using future statements. Right now, I cannot think of a single thing that cannot be made available that way. They will be, in essence, backward-compatibility hacks, but they'll work and the performance impact will be minimal. Of course, 4 is somewhat of a sweeping statement, even with the parenthesised reservation, considering some of the 3.0 features haven't been implemented yet. I'm pretty confident we can do this without comprimising 3.0, though. If we cannot, we might need to add an extra 'migration feature' in Python 2.7, or 2.8 or even 2.9 (but as it is now, I'm not sure that's specifically necessary. We may still want to release Python 2.7 and later for other reasons, of course.) The end result will be that you can write your Python code so it works in 2.6-or-later and 3.0, or -- just like now -- in 2.x-or-later (where 'x' depends on the features you use) but not 3.0. If you write careful code, you may get away with writing 2.2-or-later code that can be run in 3.0 with a single translation run. It will be fairly unlikely you can write code for 2.5-or-earlier *and* 3.0 without using the translation step, unless you live in a world blissfully unaware of anything non-ASCII. In any case, while we aren't working to make that possible, we certainly won't go out of the way to prevent it (but there still won't be any compromises in the 3.0 language just for code compatibility.) As I said, I've talked with a few people about this, both python core developers and people who develop their own software. I would like to hear from people who have concrete doubts about this upgrade path. I don't mean doubts about Python 3.0 -- this mail isn't about 3.0 at all, and I can only suggest you try out the py3k branch when the dubious feature(s) are implemented. I also don't mean doubts about how we're going to keep the performance impact minimal or how we're going to handle dict views and what not. I mean doubts about this procedure of having transitional releases between 2.5 and 3.0, and the *community* impact of 2.6+ and 3.0 this way. One thing in particular I wonder about is the warning about mixing tabs and spaces. Should it be in category 2) (on by default) or 3) (still off by default, but part of -Wpy3k)? -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] status of switch to Roundup off of SF
When I gave the PSF members an update on the work to move the python-dev tracker over to Roundup Andrew Kuchling asked me to also send an email to python-dev since October/November. As of right now the biggest thing holding up the transition is documentation. A doc needs to get written explaining basic workflow of how issues should be handled. Also need to go through and remove SF references and make them more general (e.g., mention an issue tracker when possible). After that some redirects need to be tweaked. www.python.org/sf/ needs to redirect to the Roundup installation (which is keeping SF bug numbers). bugs.python.org will also be set to point to the Roundup server. After all of that we will find out from Anthony and Neal when a release is going to be so as to do the switch when it won't run into a release (before or after). The current test tracker is at http://psf.upfronthosting.co.za/roundup/tracker/ . The meta tracker for dealing with this stuff is at http://psf.upfronthosting.co.za/roundup/meta/ . Feel free to have a look, but please don't go overboard with the suggestions on changes. It is not difficult to change the tracker after it launches. The last thing any of us want to see is the tracker launch delayed because someone wants a feature that takes a while to implement. Unless there is a critical issue you find it would be appreciated if you file the suggestion and just let us push after the launch if it is deemed it will take too much time to implement. The mailing list where all discussions take place is http://mail.python.org/mailman/listinfo/tracker-discuss . Fairly low-traffic although all updates to the meta tracker get sent there. Obviously if you have questions feel free to ask. And if you want to help with getting the switch to happen just speak up. =) -Brett ___ 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] dinner at Standard in Dallas
I'm organizing a trip to Standard in downtown Dallas for dinner tonight (Sunday night). It's about a 10 minute cab ride to Standard. We can share cabs and get there without too much trouble. The restaurant is on the expensive side. I'm thinking we should leave from the hotal around 6:30pm. http://www.standarddallas.com/ http://restaurants.dallasobserver.com/search/restaurants.php?oid=27399 A large group of us went for dinner last year and had a great time. The food was excellent, short ribs and mashed potatoes with truffles stand out in my mind. They also serve a tangerita cocktail--margerita made with Tang--that was memorable. Let me know if you'd like to come and I'll make reservations and arrange for cabs. Jeremy ___ 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] Python-3000 upgrade path
On 2/25/07, Thomas Wouters [EMAIL PROTECTED] wrote: It's about how we get Python 2.x to 3.0, and howmuch of 3.0 we put into 2.6 and later. I've also talked to a bunch of people at PyCon, including Thomas. There seems to be much concern (rightfully so!) about the upgrade path from 2.x to 3.x. I don't think it will be easy to navigate, but I have confidence we can do a great job. My goal is to rip out as much cruft from the code base for 3k to make it easier to maintain. In order for users to adopt 3k, it must provide real benefit. In addition, it as painless as possible for third party developers to support both 2.x and 3.x. All the developers I talked to expressed relief that we weren't forgetting about them. There's still unease and will be until we demonstrate what we plan to do. They were satisfied with our general approach. The time schedules in PEP 361 (2.6 release schedule) and what Guido has said for 3k (from what I remember) are roughly: April 2007 - 3.0 PEPs and features accepted/decided June 2007 - 3.0a1 - basic (most) features implemented Dec 2007 - 2.6a1 Apr 2008 - 2.6 final July 2008 - 3.0 final Even if we slip these schedules, as long as we keep them in relative order, we can keep 2.6 robust, while also offering many of the 3k features. n ___ 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] bool conversion wart?
Guido van Rossum wrote: How would this change be helpful? I'm utterly mystified by these suggestions that bool would be more useful if it didn't behave like an int in arithmetic. I think there's a desire by some people to get rid of unnecessary conceptual baggage left over for historical reasons. Those people are mystified as to why anyone would *want* a boolean to behave like an int. Personally I'm +0 on this. I wouldn't object if it happened, but I'm not pushing for it. -- Greg ___ 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] Python-3000 upgrade path
Neal Norwitz [EMAIL PROTECTED] wrote: The time schedules in PEP 361 (2.6 release schedule) and what Guido has said for 3k (from what I remember) are roughly: April 2007 - 3.0 PEPs and features accepted/decided June 2007 - 3.0a1 - basic (most) features implemented Any talk at PyCon regarding the new IO system? That looks like the biggest piece of unfinished Py3k work. Neil ___ 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] Python-3000 upgrade path
On 2/25/07, Neil Schemenauer [EMAIL PROTECTED] wrote: Neal Norwitz [EMAIL PROTECTED] wrote: The time schedules in PEP 361 (2.6 release schedule) and what Guido has said for 3k (from what I remember) are roughly: April 2007 - 3.0 PEPs and features accepted/decided June 2007 - 3.0a1 - basic (most) features implemented Any talk at PyCon regarding the new IO system? That looks like the biggest piece of unfinished Py3k work. AFAIK, there hasn't been any work on the new IO system or str/unicode unification. Guido asked for help on these, but I don't know if there were any takers. Sprints will be held over the next several days, so hopefully there will be some work in these areas. n ___ 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] Python-3000 upgrade path
Just the it's not there yet part :) There's some prototype code and email conversations archived, but no recent work that I'm aware of. On 2/25/07, Neil Schemenauer [EMAIL PROTECTED] wrote: Neal Norwitz [EMAIL PROTECTED] wrote: The time schedules in PEP 361 (2.6 release schedule) and what Guido has said for 3k (from what I remember) are roughly: April 2007 - 3.0 PEPs and features accepted/decided June 2007 - 3.0a1 - basic (most) features implemented Any talk at PyCon regarding the new IO system? That looks like the biggest piece of unfinished Py3k work. Neil ___ 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/thomas%40python.org -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Python-3000 upgrade path
On 2/25/07, Neal Norwitz [EMAIL PROTECTED] wrote: On 2/25/07, Neil Schemenauer [EMAIL PROTECTED] wrote: Any talk at PyCon regarding the new IO system? That looks like the biggest piece of unfinished Py3k work. AFAIK, there hasn't been any work on the new IO system or str/unicode unification. Guido asked for help on these, but I don't know if there were any takers. Sprints will be held over the next several days, so hopefully there will be some work in these areas. Right. To be honest, I consider the str/unicode unification a much bigger project than the new I/O library. I plan to do the new I/O library first (mostly in Python) first, hopefully at the PyCon sprint, since it can be done with the bytes and unicode objects; the old I/O library will break once we do the unification so the I/O library must be replaced before the unification can be started. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Python-3000 upgrade path
On Sun, Feb 25, 2007 at 05:37:08PM -0600, Guido van Rossum wrote: Right. To be honest, I consider the str/unicode unification a much bigger project than the new I/O library. I was more concerned about IO because it would seem to require your time for design work. The str/unicode work could be farmed out to a bunch of workers. Neil ___ 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] Python-3000 upgrade path
On 2/25/07, Neil Schemenauer [EMAIL PROTECTED] wrote: On Sun, Feb 25, 2007 at 05:37:08PM -0600, Guido van Rossum wrote: Right. To be honest, I consider the str/unicode unification a much bigger project than the new I/O library. I was more concerned about IO because it would seem to require your time for design work. The str/unicode work could be farmed out to a bunch of workers. I was more thinking of pulling a few all-nighters -- seriously, since it needs to be done as quickly as possible once it is started. The number of volunteers who want to do C code is also dwindling... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Renaming Include/object.h
On 1/3/07, Martin v. Löwis [EMAIL PROTECTED] wrote: In #1626545, Anton Tropashko requests that object.h should be renamed, because it causes conflicts with other software. I would like to comply with this requests for 2.6, assuming there shouldn't be many problems with existing software as object.h shouldn't be included directly, anyway. I like the idea of renaming the header files, but I expect there is a lot more opportunity for breaking code that you estimate. I did a search on google.com/codesearch and found seven external packages that include Python.h and object.h (before I gave up). I assume we expect people won't include it, because it is also included in object.h. But they do it. Is there documentation that says you shouldn't import it? Jeremy What do you think? 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/jeremy%40alum.mit.edu ___ 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
