Re: [Python-Dev] Coverity scan
Am 06.09.2012 10:59, schrieb Stefan Krah: > The mailing list would be nice especially if we could get the results in > verbose text form, but I don't know if that's possible. I've added my account to the notification list but I've not yet received a mail as no new issue was introduced. Coverity also sends an email for every successful or failed build. So far the mails end up in my inbox. > BTW, do we keep all buffer overruns secret or can we post them on the tracker > if it's an off-by-one and unlikely to be exploitable? I'd say use your best discretion. In the unlikely case that Coverity finds a buffer overflow that can be abused remotely we have to go through PSRT and publish security fix releases. At a first glance no bug looked that severe to me. IMHO it makes sense to define a workflow how we are going to handle Coverity issues. Each coverity issue has an identifier and can have information like an external reference and an action. I've seen that you have started to create bugs in our tracker. How about we mention the Coverity # in the bug and add a link to the bug in the "Ext. Reference" field of the Coverity issue and set the Action to "Claimed, being worked on". In case you got curious about Coverity I've created a screenshot for you http://imm.io/Duel . Christian ___ 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 2.7: only Visual Studio 2008?
Hi Martin, I'm sorry for my delayed reply, my backlog grew rather large. Am 25.08.2012 19:02, schrieb "Martin v. Löwis": > Interesting point. This somewhat breaks the stable ABI, which does > include three SetFromErrno functions. So I guess we need to warn users > of the stable ABI against using these functions. As far as I know it's only an issue an Windows. The stable ABI documentation should mention that mixing C runtime libraries may cause bugs and segfaults. As a Python core developer with some experience with Windows I'm well aware of the possible issues. Others may fall for it as the docs lack a clear warning -- or I wasn't able to find the warning quickly. > A solution would then be to add an additional set of functions which > expect errno as a parameter, although this is quite some complication. > Another solution is to introduce a Py_errno macro (and _Py_errno > function) which exposes Python's view of errno, so code that might > be confronted with this issue would write > > Py_errno = errno; > > before calling any of these functions. I like the Py_errno idea. It's simple and doesn't introduce three or more new methods. Can we still implement the feature for 3.3.0 or is it too late? > Anything else that you are aware of? AFAIK each CRT has its own thread local storage. But that's not an issue for us as we already have an API for TLS access. Christian ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-08-31 - 2012-09-07) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3681 (+28) closed 23975 (+20) total 27656 (+48) Open issues with patches: 1639 Issues opened (40) == #14223: curses addch broken on Python3.3a1 http://bugs.python.org/issue14223 reopened by Nicholas.Cole #15833: most failures to write byte-compiled file no longer suppressed http://bugs.python.org/issue15833 opened by sbt #15834: 2to3 benchmark not working under Python 3 http://bugs.python.org/issue15834 opened by brett.cannon #15835: HP-UX build needs to be tweaked to pick up PATH_MAX http://bugs.python.org/issue15835 opened by trent #15836: unittest assertRaises should verify excClass is actually a Bas http://bugs.python.org/issue15836 opened by daniel.wagner-hall #15837: Added test to test_random.py testing Random.shuffle http://bugs.python.org/issue15837 opened by eng793 #15838: make install tries to create lib2to3 grammar pickles in source http://bugs.python.org/issue15838 opened by ned.deily #15840: Ambiguity with regard to the effect of accessing a closed IOBa http://bugs.python.org/issue15840 opened by alexkon #15842: Some SocketIO methods can succeed after close() http://bugs.python.org/issue15842 opened by pitrou #15844: weird import errors http://bugs.python.org/issue15844 opened by weirdink13 #15845: Fixing some byte-to-string conversion warnings http://bugs.python.org/issue15845 opened by eng793 #15847: parse_args stopped accepting tuples http://bugs.python.org/issue15847 opened by zbysz #15848: PEP 3121, 384 Refactoring applied to xxsubtype module http://bugs.python.org/issue15848 opened by Robin.Schreiber #15849: PEP 3121, 384 Refactoring applied to xx module http://bugs.python.org/issue15849 opened by Robin.Schreiber #15851: Lib/robotparser.py doesn't accept setting a user agent string, http://bugs.python.org/issue15851 opened by dualbus #15852: typos in curses argument error messages http://bugs.python.org/issue15852 opened by cjerdonek #15853: IDLE crashes selecting Preferences menu with OS X ActiveState http://bugs.python.org/issue15853 opened by David.Pietz #15855: memoryview methods and data members are missing docstrings http://bugs.python.org/issue15855 opened by belopolsky #15856: inspect.getsource(SomeClass) doesn't show @decorators http://bugs.python.org/issue15856 opened by takluyver #15857: memoryview: complete support for struct packing/unpacking http://bugs.python.org/issue15857 opened by belopolsky #15858: tarfile missing entries due to omitted uid/gid fields http://bugs.python.org/issue15858 opened by tlynn #15859: PyUnicode_EncodeFSDefault win32 inconsistancy. http://bugs.python.org/issue15859 opened by ideasman42 #15860: Use TestCase assertion methods in unittest.mock.assert* to mak http://bugs.python.org/issue15860 opened by Julian #15861: ttk.Treeview "unmatched open brace in list" http://bugs.python.org/issue15861 opened by Bryan.Oakley #15862: IDLE not working when due to wrong Hard Drive point of os.path http://bugs.python.org/issue15862 opened by Cemal.Duman #15863: Fine-grained info about Python versions which support changes http://bugs.python.org/issue15863 opened by alexkon #15865: reflect bare star * in function signature documentation http://bugs.python.org/issue15865 opened by cjerdonek #15866: encode(..., 'xmlcharrefreplace') produces entities for surroga http://bugs.python.org/issue15866 opened by wiml #15867: make importlib documentation easier to use http://bugs.python.org/issue15867 opened by Julian #15868: leak in bytesio.c http://bugs.python.org/issue15868 opened by skrah #15869: Include .desktop file and icon http://bugs.python.org/issue15869 opened by natureshadow #15870: PyType_FromSpec should take metaclass as an argument http://bugs.python.org/issue15870 opened by belopolsky #15871: Online docs: make index search always available. http://bugs.python.org/issue15871 opened by terry.reedy #15872: shutil.rmtree(..., ignore_errors=True) doesn't ignore all erro http://bugs.python.org/issue15872 opened by jwilk #15873: "datetime" cannot parse ISO 8601 dates and times http://bugs.python.org/issue15873 opened by nagle #15874: argparse cannot parse shell variable arguments in file-given a http://bugs.python.org/issue15874 opened by ZhuangZi #15875: tarfile may not make @LongLink for non-ascii character http://bugs.python.org/issue15875 opened by Manuke #15877: xml.dom.minidom cannot parse ISO-2022-JP http://bugs.python.org/issue15877 opened by dcallagh #15879: set.__or__, __and__, etc create subclass types, but ignore __n http://bugs.python.org/issue15879 opened by Jon.Obermark #1528167: Tweak to make string.Templates more customizable http://bugs.python.org/issue1528167 reopened by r.david.murray Most recent 15 issues with n
Re: [Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
On Mon, Aug 27, 2012 at 10:56 AM, Daniel Holth wrote: > On Wed, Aug 15, 2012 at 10:49 AM, Daniel Holth wrote: >> I've drafted some edits to Metadata 1.2 with valuable feedback from > ... >> (full changeset on >> https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068) > > Metadata 1.2 is nearly 8 years old and it's Accepted but not Final. Is > it better to continue editing it, or create a new PEP for Metadata > 1.3? Somehow I completely overlooked this thread until now. Thanks Daniel for getting the ball rolling on this. There have already been many bytes spilled on metadata extensions, and although I agree it would be enormously useful to build an extension mechanism into the metadata format, I don't have much riding on that, or much more to add that hasn't been said. There hasn't been much said about Setup-Requires-Dist, so I'm guessing it's uncontroversial. But since that's sort of my hobbyhorse I thought I would make a comment on it. The thing I love about the Setup-Requires-Dist feature is that, if properly supported by different installers, it can free those installers from a fair bit of responsibility. For example, in greatly simplifies the thorny issue of "compilers". The existing compiler support in distutils, while not without its problems, does work in most cases for building common C-extensions. distutils2 has already made some progress on cleaning up the interface for compilers, and making it easier to register new compiler classes that can be imported from an arbitrary package. This allows projects with special needs (such as Fortran compiler support) to ship their own compiler class with the project. Or if there's a good enough third-party package that provides Fortran compiler support, projects may use it in their build process. Support for Setup-Requires-Dist ensures that a third-party compiler package can be made available at build-time. What's great about this, is that even if the stdlib still includes a build system, it doesn't necessarily have to anticipate every possible need for building every kind of project (it should, at a minimum, be able to build pure-Python projects). If someone wants to add MSVC2012 support they can do that as a third-party package. One could even create "compilers" for other build systems like waf, or even provide an entry-point to meta-build systems like bento. Am I making sense? Erik ___ 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] core dev IRC nicks
On Tue, Aug 28, 2012 at 9:31 PM, Nick Coghlan wrote: > On Wed, Aug 29, 2012 at 1:58 PM, Chris Jerdonek > wrote: >> Is there a list somewhere of the IRC nicks of the core developers that >> use IRC (and who wish to be listed) alongside their real names? If >> there is no such list, has there ever been discussion on python-dev of >> creating such a list? > > No, to all those questions. It's not a bad idea, though. > > One possibility (if someone was willing to work on it) would be to > enhance our Roundup instance to handle it. (See > http://docs.python.org/devguide/tracker.html#the-meta-tracker) > > Allow users to add their typical IRC handle, and perhaps add a > "Committers List" link below the existing "Users List" link in the > sidebar. I created an issue for the latter here: http://psf.upfronthosting.co.za/roundup/meta/issue479 --Chris ___ 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
