Re: [Python-Dev] DTRACE support
On Sat, 7 Sep 2013 08:57:07 +0200 Xavier Morel wrote: > > On 2013-09-07, at 05:40 , Jesus Cea wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 06/09/13 20:33, Antoine Pitrou wrote: > >> On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea wrote: > >>> > >>> It is intrusive. Yes. I think it must be, by its own nature. > >>> Probably room for improvement and code transparency. But... are > >>> Python-DEVs interested in the project?. That is the point :) > >> > >> As a concrete data point: - here are Dave's modifications to > >> ceval.c for systemtap: > >> http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here > >> are your modifications to ceval.c for dtrace: > >> http://bugs.python.org/review/13405/diff/6151/Python/ceval.c > > > > Unfair, because that code is not doing the same thing. > > > > Most of the extra complexity is there to deal with DTRACE ability to > > provide meaningful stackframes, with Python code instead of CPython > > evaluation loop. This is kind of magical. > > Antoine will correct me if I'm wrong, but I believe his point is less > about the complexity of dtrace provision and more about how much of it > lives in ceval.c: the systemtap provision also takes quite a bit of > code, but almost all of that code is extracted into a separate file and > only a pair of calls live in ceval.c Yes, that's exactly my point. There can be an arbitrarily complex ceval-dtrace.h for all I care :-) Thanks for the examples, by the way. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] when to fix cross-version bugs?
On 7 Sep 2013 02:43, "Ethan Furman" wrote: > > On 09/06/2013 07:51 AM, Ethan Furman wrote: >> >> >> What guidelines determine when a bug is fixed in previous versions? > > > On 09/06/2013 08:29 AM, Brian Curtin wrote: >> >> >> If it's a bug in that version and the version is accepting bug fixes, >> i.e., not in security mode, go for it. This includes crossing the 2/3 >> boundary if applicable. > > > On 09/06/2013 08:31 AM, R. David Murray wrote: >> >> >> The basic guideline is: we try very hard not to break currently working >> code in a maintenance release. Making that decision very much depends on >> the details of each individual case. >> >> [so] it probably doesn't have much positive impact if it does get >> >> backported, so is it worth the (small) chance of breaking someone's code? > > > And they say never go to the elves for advice! ;) Fixes that risk breaking current doctests are rarely worth backporting, so in this case, I'd say only fixing it in 3.4 is the better option. Definitely the kind of borderline case worth asking about, though :) Cheers, Nick. > > > -- > ~Ethan~ > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DTRACE support
On 7 September 2013 19:06, Antoine Pitrou wrote: > On Sat, 7 Sep 2013 08:57:07 +0200 > Xavier Morel wrote: >> >> On 2013-09-07, at 05:40 , Jesus Cea wrote: >> >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA1 >> > >> > On 06/09/13 20:33, Antoine Pitrou wrote: >> >> On Fri, 06 Sep 2013 18:14:26 +0200 Jesus Cea wrote: >> >>> >> >>> It is intrusive. Yes. I think it must be, by its own nature. >> >>> Probably room for improvement and code transparency. But... are >> >>> Python-DEVs interested in the project?. That is the point :) >> >> >> >> As a concrete data point: - here are Dave's modifications to >> >> ceval.c for systemtap: >> >> http://bugs.python.org/review/14776/diff/5177/Python/ceval.c - here >> >> are your modifications to ceval.c for dtrace: >> >> http://bugs.python.org/review/13405/diff/6151/Python/ceval.c >> > >> > Unfair, because that code is not doing the same thing. >> > >> > Most of the extra complexity is there to deal with DTRACE ability to >> > provide meaningful stackframes, with Python code instead of CPython >> > evaluation loop. This is kind of magical. >> >> Antoine will correct me if I'm wrong, but I believe his point is less >> about the complexity of dtrace provision and more about how much of it >> lives in ceval.c: the systemtap provision also takes quite a bit of >> code, but almost all of that code is extracted into a separate file and >> only a pair of calls live in ceval.c > > Yes, that's exactly my point. There can be an arbitrarily complex > ceval-dtrace.h for all I care :-) > > Thanks for the examples, by the way. Yep, complex stuff inline should be abstracted out so it doesn't affect the code flow for those of us that don't care :) Between Jesus, the Mac OS X using core devs and the Solaris and Mac OS X buildbots it should be a maintainable addition. However, it seems worthwhile to write up a short PEP (akin to the tracemalloc PEP) to scope out the suggestion. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Redesigning extension modules
On Mon, Sep 2, 2013 at 7:02 AM, Nick Coghlan wrote: > The hook API I currently have in mind is a two step initialisation: > > PyImport_PrepareNAME (optional) > PyImport_ExecNAME > Should we also look at an API change for the initfunc() of PyImport_Inittab entries? Currently the function takes a module name, which doesn't jive with loader.exec_module() taking a module. I noticed this while adding an exec_module() to BuiltinImporter. I suppose the same thing goes for PyImport_ImportFrozenModuleObject(). -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
