Re: [Python-Dev] to rename or not...
Le Wed, 31 Jul 2013 08:15:50 +0200, Ronald Oussoren a écrit : > > Because of this I'd like to introduce a new API in plistlib that > fixes both problems. In particular: > > * Add 'load', 'loads', 'dump' and 'dumps', those use "bytes" for > binary data by default > > * Keep and deprecate "readPlist", "writePlist" and the their string > equivalents, those still use Data objects (and call the new API to do > the actual work). > > I'd like some feedback on this change. On the one hand the new APIs > make it possible to clean up the API of plistlib, on the other hand > this is a big API change. +1 on the principle. I can't say more, not being a Mac user. Regards Antoine. ___ 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] to rename or not...
Ronald Oussoren wrote: * Add 'load', 'loads', 'dump' and 'dumps', those use "bytes" for binary data by default * Keep and deprecate "readPlist", "writePlist" and the their string equivalents, those still use Data objects +1, makes sense to me. -- 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] to rename or not...
On Wed, 31 Jul 2013 20:39:10 +1200, Greg Ewing wrote: > Ronald Oussoren wrote: > > * Add 'load', 'loads', 'dump' and 'dumps', those use "bytes" for binary data > > by default > > > > * Keep and deprecate "readPlist", "writePlist" and the their string > > equivalents, those still use Data objects > > +1, makes sense to me. Yes, +1. Presumably the plistlib module was "ported" to py3k just enough to make it pass its tests, without reconsidering the design (and API) the way you have now done. So I think it is appropriate to do so. But, then, I would, considering I'm doing the same thing to the email module for much the same reason :). --David ___ 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] to rename or not...
On 31 Jul, 2013, at 10:09, Antoine Pitrou wrote: > Le Wed, 31 Jul 2013 08:15:50 +0200, > Ronald Oussoren a écrit : >> >> Because of this I'd like to introduce a new API in plistlib that >> fixes both problems. In particular: >> >> * Add 'load', 'loads', 'dump' and 'dumps', those use "bytes" for >> binary data by default >> >> * Keep and deprecate "readPlist", "writePlist" and the their string >> equivalents, those still use Data objects (and call the new API to do >> the actual work). >> >> I'd like some feedback on this change. On the one hand the new APIs >> make it possible to clean up the API of plistlib, on the other hand >> this is a big API change. > > +1 on the principle. I can't say more, not being a Mac user. plistlib is the portable part of the stdlib :-) But anyway, I've got enough positive feedback that I'll introduce the new API, although it probably won't make the first alpha release. Ronald ___ 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] C code coverage report with lcov
On Tue, Jul 30, 2013 at 8:28 PM, Christian Heimes wrote: > Am 29.07.2013 21:48, schrieb Antoine Pitrou: > > Ideally, we should run coverage runs on different systems (Unices, > > Windows...) and merge the results together, so that we know which paths > > are really uncovered. > > I don't that is easily possible. The coverage report depends on GCC and > its gcov extension -- so much for Windows. I also don't know if gcov > supports cross-profiling on varying platforms and operating systems. > > By the way gcov understands preprocessor output. It doesn't report lines > as uncovered when the lines or functions are #ifdef-ed out. > In case are curious to try and make this work using clang, I found the flags to use at http://clang-developers.42468.n3.nabble.com/Code-coverage-on-clang-td4033066.html and how to make it work with lcov. I also discovered clang itself uses https://github.com/ddunbar/zcov instead of lcov. This is all untested, but I didn't want to forget the links and in case someone has clang installed with compiler-rt and wants to see how it works. ___ 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
