Re: [Python-Dev] The end of 2.7
;) there's the missing bit. btw apologies if that looked offensive: it wasn't intended. I disagree on "bilingual extension modules are easier". While #ifdef can sort some issues (compiling ones mostly) it won't be much of a help if a module crash (and not much help from testing either). In that case debugging it involves a lot of steps as gatering the core dumps (if available), having a readily build python debug version, a debugger and restoring the crashing system in a similar state. All these steps might not be possible at all (imagine a secured production server). I'm not saying it is not possible but the caused downtime can quickly escalate (think of it in days terms more than hours). These are hidden costs to a company and it is hard to convince anyone to agressively port something to 3.x if it is reliably working on let's say 2.x: especially under time pressure conditions. On the bright side there's some success moving into 2.7: and we can all make sure the move to 3.x will be as small as possible in case in future time/policy constraints are relaxed. Thanks, Antonio On 2013-04-09 00:48, Barry Warsaw wrote: On Apr 08, 2013, at 11:32 PM, Antonio Cavallo wrote: Cool, next time I have to port an extension written in C/C++ I'll be looking only for bytes vs. strings problems. I knew it was easy. Since I didn't see a smiley, I'll assume that wasn't sarcastic. ;) In some ways bilingual extension modules are easier because of #ifdef, but the general principle still holds. If you have a clear bytes v. strings story, it's not really that difficult to port extension modules either, at least IME. -Barry ___ 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] Accelerating extension module compilation [distutils]
Hi, Apologies if this is the wrong place to ask, but thought this question would be relevant to Python core and extension module devs.. This the right place? I've been using distutils to compile C++ extensions / bindings written with Boost.Python, and have been implementing some (often frowned-upon) monkey-patching magic to speed up the compilation process. I was wondering if other Python devs would appreciate the benefit from a distutils-integrated patch of the same functionality, using less-frowned upon programming techniques. More specifically, I have felt it useful during development to incorporate the following functionality into a setupext.py file:- 1. Parallel compilation, by monkey-patching distutils.ccompiler.CCompiler.compile. (A basic solution was provided on StackOverflow[1].) 2. Create a "unity-build"[2]. 3. Only re-compile objects whose source-code / included files have changed. I'll happily share my code (hacks), but before getting too technical with the discussion, I was just wondering whether any of these would be considered useful enough / easy enough to implement without breaking backwards-compatibility, to incorporate into core distutils. Any thoughts? Thanks for your time. Kind regards, Alex [1] - http://stackoverflow.com/questions/11013851/speeding-up-build-process-with-distutils [2] - http://stackoverflow.com/questions/543697/include-all-cpp-files-into-a-single-compilation-unit -- Using Opera's mail client: http://www.opera.com/mail/ ___ 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] [Python-checkins] cpython (3.3): Process DEFAULT values in mock side_effect that returns iterator.
My bad, sorry On Mon, Apr 8, 2013 at 8:03 PM, Antoine Pitrou wrote: > On Mon, 8 Apr 2013 10:52:30 +0100 > Michael Foord wrote: >> On 7 April 2013 14:44, andrew.svetlov wrote: >> >> > http://hg.python.org/cpython/rev/18fd64f1de2d >> > changeset: 83179:18fd64f1de2d >> > branch: 3.3 >> > user:Andrew Svetlov >> > date:Sun Apr 07 16:42:24 2013 +0300 >> > summary: >> > Process DEFAULT values in mock side_effect that returns iterator. >> > >> > Patch by Michael Ford. >> > > [...] >> >> This was committed without a NEWS entry. > > And I wonder who that Michael Ford is :-) > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ 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
