Re: [Python-Dev] debug and release python
What I mean is that a third party software vendor supplies a foobarapp.pyd and a foobarapp_d.pyd dlls that link to python2x.dll and python2x_d.dll respectively. But the latter will have been compiled to match a certain settings of the objimpl.h header, which may not match whatever is being used to build the local python2x_d.dll. And thus, you get strange and hard to debug linker errors when trying to load external libraries. When developing superapp.exe, which uses a custom build of python2x, perhaps even embedded, python2x_d.dll is used extensively both during the development process and the testing process. This is why foobarapp_d.pyd is necessary and why it is supplied by any sensible vendor providing opaque python extensions. But the current objimpl.h api makes it a matter of developer choice whether that foobarapp_d.pyd will successfully link with your python2x_d.dll or not. IMHO, it is not good practice to expose an API that changes depending on preprocessor settings like this. K > -Original Message- > From: "Martin v. Löwis" [mailto:[email protected]] > Sent: 14. júní 2010 22:13 > To: Kristján Valur Jónsson > Cc: [email protected] > Subject: Re: [Python-Dev] debug and release python > > > Some external software comes with proprietary .pyd bindings. > > Can you please explain what a "proprietary .pyd binding" is? > > Do you mean they come with extension modules? If so, there is no chance > of using them in debug mode, anyway, right? So what specifically is the > problem? > > 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
[Python-Dev] Become a Python contributor at PyOhio
Thanks to David Murray, we're going ahead with plans to make a full-fledged introduction to core development at PyOhio. We've just started circulating this announcement to drum up interest, so if there are people or groups who you'd like to recruit to the effort, please forward it to them. By the way, I haven't made a peep on this list yet - or even read it - because I'm intentionally preserving my ignorance so that I can be the leader-learner for the Teach Me session. (It's the first time wilful ignorance has actually been a virtue). Anyway, the announcement: Become a Python contributor at PyOhio = Working in Python is awesome. Are you ready to work on Python? The quality of Python and the Standard Library depend on volunteers who fix bugs and make improvements to the codebase. If you're interested in joining these volunteers, good for you! Information on core development is right on Python's homepage. However, if you'd like an in-person boost to get you started, come to PyOhio this July 31 - August 3. One of our many events is "Teach Me Python Bugfixing", an introduction to working on Python that's guaranteed newbie-friendly (because a newbie is running it). Next come two evenings and two full days of Python core sprinting, so you can put your new skills to use with plenty of helpers around. It's classroom learning and real-life practice at one free event! See you there! Core development: http://www.python.org/dev/ PyOhio: http://www.pyohio.org/ Teach Me Python Bugfixing: http://www.pyohio.org/2010/Talks#A.234_Teach_Me_Python_Bugfixing PyOhio sprints: http://www.pyohio.org/Sprints2010 -- - Catherine http://catherinedevlin.blogspot.com/ *** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.org *** ___ 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] debug and release python
Am 15.06.2010 14:48, schrieb Kristján Valur Jónsson: What I mean is that a third party software vendor supplies a foobarapp.pyd and a foobarapp_d.pyd dlls that link to python2x.dll and python2x_d.dll respectively. But the latter will have been compiled to match a certain settings of the objimpl.h header, which may not match whatever is being used to build the local python2x_d.dll. And thus, you get strange and hard to debug linker errors when trying to load external libraries. Ok. But your proposed change doesn't fix that, right? I.e. even with the change, it would *still* depend on objimpl.h (and other) settings what ABI this debug DLL exactly has. So I think this problem can't really be fixed. Instead, you have to trust that the vendor did the most sensible thing when building foobarapp.pyd, namely activating *just* the debug build. Then, if you do the same, it will interoperate just fine. IMHO, it is not good practice to expose an API that changes depending on preprocessor settings like this. But there are tons of ABI changes that may happen in a debug build. If you want to cope with all of them, you really need to recompile the source of all extensions. 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] debug and release python
2010/6/14 Kristján Valur Jónsson : > Hello there. > > I‘m sure this has come up before, but here it is again: > > > > Python exports a different api in debug mode, depending on whether > PYMALLOC_DEBUG and WITH_PYMALLOC are exported. This means that _d.pyd files > that are used must have been compiled with a version of python using the > same settings for these macros. It is unfortunate that the > _PyObject_DebugMalloc() api is exposed to external applications using macros > in objimpl.h > > > > I would suggest two things: > > 1) provide dummy or thunking versions of those in builds that don‘t > have PYMALLOC_DEBUG impolemented, that thunk to PyObject_Malloc et al. (This > is what we have done at CCP) > > 2) Remove the _PyObject_DebugMalloc() from the api. It really should > be an implementation of in the exposed PyObject_Malloc() functions whether > they use debug functionality at all. the _PyObject_DebugCheckAddress and > _PyObject_DebugDumpAddress() can be left in place. But exposing this > functionality in macros that external moduled compile in, is not good at > all. > > The reason why this is annoying: > > Some external software comes with proprietary .pyd bindings. When > developing my own application, with modified preprocessor definitions (e.g. > to turn off PYMALLOC_DEBUG) we find that those externally provided libraries > don‘t work. It takes a fair amount of detective work to find out why > exactly linkage fails. The external API really shouldn‘t change depending > on preprocessor definitions. I remember having the same issue years ago: http://mail.python.org/pipermail/python-list/2004-July/855844.html At the time, I solved the issue by compiling extension modules with pymalloc options turned on (which it fortunately the default, so this applies to the supplied proprietary .pyd), and I added a (plain) definition for functions like _PyObject_DebugMalloc, even when PYMALLOC_DEBUG is undefined. Since the python_d.dll is a custom build anyway, adding the code is not too much pain. -- Amaury Forgeot d'Arc ___ 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] Become a Python contributor at PyOhio
On Tue, Jun 15, 2010 at 4:34 PM, Dan Buch wrote: > Does this mean I should repurpose my talk slot, currently entitled > "Intro to Core Involvement"? :) > > Ach! I forgot! Hopefully that's the dumbest mistake I'll make in this year's PyOhio preparations. Fortunately the PyCon blog can be edited... wish emails could be. No, as I wrote to the talk committee, "There is some overlap between this talk and Dan Buch's submission, though his seems to have a heavier focus on doc and triage work. If they're both selected, I'll work with Dan to see that the talks dovetail well together. I would really *love* to see Dan's talk, this talk, and sprints (weekend sprints AND sprints on the following weekdays) fuse into a great big contribu-palooza that will put PyOhio on the map! Well, we're already on the map." I actually think it'll be ideal if we can get - Your talk midday on Saturday, for a clasically planned introduction on multiple aspects of core involvement - Shortly thereafter, my "teach me" talk, which will be specifically about bugfixing and will focus on points of newbie confusion by means of my own all-natural fumbling. Hopefully some people from your talk's audience will take their brand-new knowledge to participate in the "teach me" session as both teachers and learners... nothing solidifies learning like teaching does. (I think I need to *not* watch your talk until afterward on video, incidentally, to keep my ignorance pure. I might end up as the most ignorant person in the room, which would be perfect.) - That evening, the sprinty goodness begins. -- - Catherine http://catherinedevlin.blogspot.com/ *** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.org *** ___ 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] Become a Python contributor at PyOhio
So let's try this again: Become a Python contributor at PyOhio = Working in Python is awesome. Are you ready to work on Python? The quality of Python and the Standard Library depend on volunteers who fix bugs and make improvements to the codebase. If you're interested in joining these volunteers, good for you! Information on core development is right on Python's homepage. However, if you'd like an in-person boost to get you started, come to PyOhio this July 31 - August 3. Two talks will get you up to speed on Python contribution: "Intro to Core Involvement" and "Teach Me Python Bugfixing". Next come two evenings and two full days of Python core sprinting, so you can put your new skills to use with plenty of helpers around. It's classroom learning and real-life practice at one free event! See you there! Core development: http://www.python.org/dev/ PyOhio: http://www.pyohio.org/ Intro to Core Development: http://www.pyohio.org/2010/Talks#A.2320_Intro_to_Core_Involvement Teach Me Python Bugfixing: http://www.pyohio.org/2010/Talks#A.234_Teach_Me_Python_Bugfixing PyOhio sprints: http://www.pyohio.org/Sprints2010 -- - Catherine http://catherinedevlin.blogspot.com/ *** PyOhio 2010 * July 31 - Aug 1 * Columbus, OH * pyohio.org *** ___ 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
