Re: [Python-Dev] Breaking undocumented API
On Fri, 12 Nov 2010 20:38:16 -0800 Guido van Rossum wrote: > > Note that __all__ was originally invented to give "from package import > *" a well-defined meaning when the package included submodules that > might not have been loaded yet. Using it for other export control > (while a good idea) could be considered "newfangled". :-) Newfangled in a rather old way already, then, perhaps :p 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
On Fri, 12 Nov 2010 20:31:49 -0500 Terry Reedy wrote: > > > class NetworkedNNTP_SSLTests(NetworkedNNTPTestsMixin, > > unittest.TestCase): > > -NNTP_HOST = 'snews.gmane.org' > > -GROUP_NAME = 'gmane.comp.python.devel' > > -GROUP_PAT = 'gmane.comp.python.d*' > > gmane is most problematical on weekends. Well we've had buildbot failures in the middle of the week. > > +NNTP_HOST = 'nntp.aioe.org' > > +GROUP_NAME = 'comp.lang.python' > > +GROUP_PAT = 'comp.lang.*' > > aioe went away for several months a couple of years ago or so. > Let us hope it stays up for awhile now. > The ssl connection currently does not work (expired certificate). Funny, it shows that the NNTP SSL tests don't check the certificate, then. 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/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
+1 on everything. 2010/11/11 Alexander Belopolsky : > 2010/11/11 Michael Foord : > .. >>> You mean runtime automation, e.g. creating __all__ on the fly omitting >>> underscored names? >>> >> Writing code to generate a __all__ that duplicates the default behaviour >> seems redundant to me. >> > > FWIW, I like having __all__ at the top of the module. It feels like a > table of contents at the start of a chapter. In some cases it may > also serve as an optimization when len(__all__) is much smaller than > len(__dict__). I also don't like _ prefix to become an exclusive > means to express privateness. > > I think the current definition of "public names" is a good one and > just needs to be made more visible in the docs. If the module defines > __all__, that should be the ultimate answer to what is public in that > module. (Users should learn to use help(module) instead of > dir(module) for API discovery.) If __all__ is not defined in the > module, I think it is good to introduce it after a careful review of > what it should contain. And __all__ should never contain names that > start with _. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > ___ 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] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
On Nov 13, 2010, at 7:08 AM, Antoine Pitrou wrote: > Funny, it shows that the NNTP SSL tests don't check the certificate, > then. Unsurprising, given that you need 140 lines of pretty non-obvious python code to do so... James ___ 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] Stable buildbots
Hi, Just to let you know that we now have 8 stable buildbots, including Barry's own PPC Ubuntu machine (even though the Windows buildbots give a rather unconventional meaning to the word "stability"). Right now they are mostly green: http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable cheers Antoine. ___ 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] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
On Sat, 13 Nov 2010 07:30:05 -0500 James Y Knight wrote: > On Nov 13, 2010, at 7:08 AM, Antoine Pitrou wrote: > > Funny, it shows that the NNTP SSL tests don't check the certificate, > > then. > > Unsurprising, given that you need 140 lines of pretty non-obvious python code > to do so... You must have missed the new match_hostname() function: http://docs.python.org/dev/library/ssl.html#ssl.match_hostname (its implementation is 50 lines rather than 140 lines, though) 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/archive%40mail-archive.com
Re: [Python-Dev] buildbot master update
On Fri, Nov 12, 2010 at 9:29 AM, "Martin v. Löwis" wrote: > As you may have noticed: I updated the buildbot master to release 0.8.2. > If you notice any problems, please post them here. One effect of this change seems to be that bbreport[1] no longer works, since it appears that buildbot 0.8.2 has done away with the XMLRPC interface that bbreport uses. But that's really a bbreport issue rather than a buildbot one... Mark [1] http://code.google.com/p/bbreport/ ___ 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] buildbot master update
Am 13.11.2010 14:00, schrieb Mark Dickinson: > On Fri, Nov 12, 2010 at 9:29 AM, "Martin v. Löwis" wrote: >> As you may have noticed: I updated the buildbot master to release 0.8.2. >> If you notice any problems, please post them here. > > One effect of this change seems to be that bbreport[1] no longer > works, since it appears that buildbot 0.8.2 has done away with the > XMLRPC interface that bbreport uses. > > But that's really a bbreport issue rather than a buildbot one... > > Mark I've added a quickfix by copying the removed xmlrpc interface to the local buildbot installation now. I had to patch it up a bit though, because of an apparent API change somewhere in buildbot, and I'm not sure whether this was correct. Georg ___ 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] Issues 9931 and 9055 - test_ttk_guionly and buildbot run as a service
On 2010/11/13 2:07, Terry Reedy wrote: On 11/12/2010 3:44 AM, Paul Moore wrote: Hi, My buildbot has been failing for some time because of these 2 issues, both related to the fact that tests are hanging when run as a service (and hence have no display to open GUI elements on). Both issues have patches, and as far as I am aware, the patches fix the issues reasonably well. What can I do to move these 2 issues forwards? As things stand, my buildbot is not providing a lot of value on the 3.x branch :-( http://bugs.python.org/issue9055 is marked as a 2.7 issue only, perhaps fixed by Tim Golden's committed patches. Should it be re-versioned for 3.1/2? There is no patch file attached, though perhaps the code in Yamamoto's message is meant as such (but for which version?). So the first thing you could do is clarify the current status and remaining issue on the tracker. http://bugs.python.org/issue9931 by Yamamoto is marked for all 3 versions. It seems to be a similar issue, though marked 'test' rather than 'ctypes'. It does have a patch by him apparently based on his previous comments. The issue has no responses and needs a patch review. So the first thing you could do is to provide one;-). If it looks great (no changes that you can think of) and works great, say so. Then it can move on to commit review stage. PS. Providing links like the above makes it easier for multiple people to take a look and respond. My patch won't fix issue9055 directly, but solves issue9931. Probably it's easy to create a patch to fix issue9055 based on my patch. One problem is, how to skip test. With single decorator like skip_unless_symlink? Or let requires() raise SkipTest? ___ 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] Removal of Win32 ANSI API
On 2010/11/12 4:26, Victor Stinner wrote: > On Thursday 11 November 2010 17:07:28 Hirokazu Yamamoto wrote: >> Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA) >> and only use Win32 WIDE API (ie: GetFileAttributesW)? >> Mainly in posixmodule.c. > > Even if I hate the MBCS encoding, because it replaces undecodable characters > by similar glyphs by default, I'm not certain that it is a good idea to drop > the bytes API. On 2010/11/12 21:08, Victor Stinner wrote: On Thursday 11 November 2010 23:01:32 you wrote: Sure, it will divide the number of lines, of the code specific to Windows, by two. Can we get most of the code cleanup benefit without the backwards compatibility risk by doing the decode from 'mbcs' on our side of the fence? I created PyUnicode_FSDecoder, a ParseTuple converter used to work on unicode paths, instead of bytes paths. On Windows, this converter uses mbcs encoding in strict mode, whereas Windows converter uses replace error handler to decode, and ignore to encode. So I don't think that we should this converter on Windows. That is, have code that was the C equivalent of: arg_is_bytes = not isinstance(arg, str) if arg_is_bytes: val = _decode_mbcs(arg) # Decoding error checking here else: val = arg # Common processing using WIDE API if arg_is_bytes: result = _encode_mbcs(wide_result) # Encoding error checking here else: result = wide_result This doesn't make the code shorter, it may be longer than the actual code, and it is less compliant with the Windows native API... Is it possible to implement new PyArg_ParseTuple converter to use PyUnicode_Decode(const char *s, Py_ssize_t size, const char *encoding, /* mbcs */ const char *errors) /* replace */ and use it? ___ 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] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
On 11/13/2010 7:08 AM, Antoine Pitrou wrote: On Fri, 12 Nov 2010 20:31:49 -0500 Terry Reedy wrote: class NetworkedNNTP_SSLTests(NetworkedNNTPTestsMixin, unittest.TestCase): -NNTP_HOST = 'snews.gmane.org' -GROUP_NAME = 'gmane.comp.python.devel' -GROUP_PAT = 'gmane.comp.python.d*' gmane is most problematical on weekends. Well we've had buildbot failures in the middle of the week. Why I did not say 'only' ;-). +NNTP_HOST = 'nntp.aioe.org' +GROUP_NAME = 'comp.lang.python' +GROUP_PAT = 'comp.lang.*' aioe went away for several months a couple of years ago or so. Let us hope it stays up for awhile now. The ssl connection currently does not work (expired certificate). More specifically, if, with Thunderbird, I turn on SSL/TLS, (which switches from port 119 to 563), I get *invalid* certificate message - good for aioe.org, news.aioe,org, but not nntp.aioe.org. I believe SSL worked before the hiatus so it might be an oversight in restarting. Funny, it shows that the NNTP SSL tests don't check the certificate, then. Or not thoroughly. -- Terry Jan Reedy ___ 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] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
O More specifically, if, with Thunderbird, I turn on SSL/TLS, (which switches from port 119 to 563), I get *invalid* certificate message - good for aioe.org, news.aioe,org, but not nntp.aioe.org. I believe SSL worked before the hiatus so it might be an oversight in restarting. Funny, it shows that the NNTP SSL tests don't check the certificate, then. Or not thoroughly. I can access gmane with SSL, so you could add a conditional (on being up and running) certificate check using that. -- Terry Jan Reedy ___ 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] r86451 - python/branches/py3k/Misc/NEWS
On 11/13/2010 8:25 AM, georg.brandl wrote: Author: georg.brandl Date: Sat Nov 13 14:25:40 2010 New Revision: 86451 - unused undocumented value PyBUF_SHADOW, and strangely-looking code in + undocumented value PyBUF_SHADOW, and strangely-looking code in For future reference, 'strangely-looking' should be either 'strange- looking' or 'strangely appearing'. First, '-ly' adverbs are never hypenated even when modifying adjectives. Second, 'strangely looking code' would mean that the code is actively looking around strangely (as opposed to passively sitting there appearing strange). tjr ___ 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] r86453 - in python/branches/release31-maint: Include/patchlevel.h Lib/distutils/__init__.py Lib/idlelib/idlever.py Misc/NEWS Misc/RPM/python-3.1.spec README
On 11/13/2010 12:28 PM, benjamin.peterson wrote: Author: benjamin.peterson Date: Sat Nov 13 18:28:56 2010 New Revision: 86453 Modified: python/branches/release31-maint/README == --- python/branches/release31-maint/README (original) +++ python/branches/release31-maint/README Sat Nov 13 18:28:56 2010 @@ -1,5 +1,5 @@ -This is Python version 3.1.2 - +This is Python version 3.1.2 release candidate 1 + That should be 3.1.3 ;-) ___ 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] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
Antoine Pitrou wrote: > On Sat, 13 Nov 2010 07:30:05 -0500 > James Y Knight wrote: > > On Nov 13, 2010, at 7:08 AM, Antoine Pitrou wrote: > > > Funny, it shows that the NNTP SSL tests don't check the certificate, > > > then. > > > > Unsurprising, given that you need 140 lines of pretty non-obvious python > > code to do so... > > You must have missed the new match_hostname() function: > http://docs.python.org/dev/library/ssl.html#ssl.match_hostname > > (its implementation is 50 lines rather than 140 lines, though) On the client side, it's pretty easy to see an invalid (say, expired) certificate. Just call get_server_certificate(), which will fail if the server certificate is invalid. That's a separate issue from matching the request hostname to the various host identifiers in the certificate, which various application protocols may or may not require. Bill ___ 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] [RELEASED] Python 3.1.3 release candidate 1
On behalf of the Python development team, I'm gladsome to announce a release candidate of the third bugfix release for the Python 3.1 series, Python 3.1.3. This bug fix release fixes numerous issues found in 3.1.2. Please try it with your packages and report any bugs you find. The final of 3.1.3 is scheduled to be released in two weeks. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. To download Python 3.1.3 visit: http://www.python.org/download/releases/3.1.3/ A list of changes in 3.1.3 can be found here: http://svn.python.org/projects/python/tags/r313rc1/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.3's contributors) ___ 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] [RELEASED] Python 2.7.1 release candidate 1
On behalf of the Python development team, I'm chuffed to announce the a release candidate of Python 2.7.1. Please test the release candidate with your packages and report any bugs you find. 2.7.1 final is scheduled in two weeks. 2.7 includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7.1 visit: http://www.python.org/download/releases/2.7.1/ The 2.7.1 changelog is at: http://svn.python.org/projects/python/tags/r271rc1/Misc/NEWS 2.7 documentation can be found at: http://docs.python.org/2.7/ This is a testing release, so we encourage developers to test it with their applications and libraries. Please report any bugs you find, so they can be fixed in the final release. The bug tracker is at: http://bugs.python.org/ Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 2.7.1's contributors) ___ 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] Removal of Win32 ANSI API
On Saturday 13 November 2010 17:21:37 you wrote: > On 2010/11/12 4:26, Victor Stinner wrote: > > On Thursday 11 November 2010 17:07:28 Hirokazu Yamamoto wrote: > >> Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA) > >> and only use Win32 WIDE API (ie: GetFileAttributesW)? > >> Mainly in posixmodule.c. > > > > Even if I hate the MBCS encoding, because it replaces undecodable > > characters > > > by similar glyphs by default, I'm not certain that it is a good idea > > to drop > > > the bytes API. > > On 2010/11/12 21:08, Victor Stinner wrote: > > On Thursday 11 November 2010 23:01:32 you wrote: > >>> Sure, it will divide the number of lines, of the code specific to > >>> Windows, by two. > >> > >> Can we get most of the code cleanup benefit without the backwards > >> compatibility risk by doing the decode from 'mbcs' on our side of the > >> fence? > > > > I created PyUnicode_FSDecoder, a ParseTuple converter used to work on > > unicode paths, instead of bytes paths. On Windows, this converter uses > > mbcs encoding in strict mode, whereas Windows converter uses replace > > error handler to decode, and ignore to encode. So I don't think that we > > should this converter on Windows. > > > >> That is, have code that was the C equivalent of: > >> > >> arg_is_bytes = not isinstance(arg, str) > >> > >> if arg_is_bytes: > >>val = _decode_mbcs(arg) > >># Decoding error checking here > >> > >> else: > >>val = arg > >> > >> # Common processing using WIDE API > >> > >> if arg_is_bytes: > >>result = _encode_mbcs(wide_result) > >># Encoding error checking here > >> > >> else: > >>result = wide_result > > > > This doesn't make the code shorter, it may be longer than the actual > > code, and it is less compliant with the Windows native API... > > Is it possible to implement new PyArg_ParseTuple converter to use > PyUnicode_Decode(const char *s, > Py_ssize_t size, > const char *encoding, /* mbcs */ > const char *errors) /* replace */ > and use it? Yes, but how do you check if the input argument is a bytes or a str object with your PyArg_Parse converter? You should use "O" format and manually convert it to unicode, and then convert the result back to bytes (if the input was bytes). It don't think that it makes the code shorter. The code is currently working. The question is if we have to drop the ANSI API now, later or never. It looks like the decision moves to "later" (deprecate in 3.2, remove in 3.3). I still think that drop now doesn't really hurt. Victor ___ 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] Removal of Win32 ANSI API
On Sun, 14 Nov 2010 01:06:55 +0100 Victor Stinner wrote: > > The code is currently working. The question is if we have to drop the ANSI > API > now, later or never. If the code is currently working and isn't a security hole, then we obviously don't "have to". Apparently several developers "want to", which is different. > It looks like the decision moves to "later" (deprecate in > 3.2, remove in 3.3). I still think that drop now doesn't really hurt. If you drop code without first deprecating it, chances are it will hurt someone. That's why having a deprecation period is the rule we usually follow (most of the time :-)). 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/archive%40mail-archive.com
Re: [Python-Dev] Removal of Win32 ANSI API
On Sun, Nov 14, 2010 at 10:19 AM, Antoine Pitrou wrote: > On Sun, 14 Nov 2010 01:06:55 +0100 > Victor Stinner wrote: >> >> The code is currently working. The question is if we have to drop the ANSI >> API >> now, later or never. > > If the code is currently working and isn't a security hole, then we > obviously don't "have to". > Apparently several developers "want to", which is different. We should also keep in mind that *Microsoft* have chosen to keep the bytes Win32 APIs around, despite their flaws, all in the name of backwards compatibility. While the goal of nudging third party developers towards the superior Unicode APIs is an admirable one, it is still the case that there is a *lot* of ASCII-only code out there. E.g. applications could easily be storing filenames in an ASCII only datastore that provides them back to the application as bytes in 3.x. >> It looks like the decision moves to "later" (deprecate in >> 3.2, remove in 3.3). I still think that drop now doesn't really hurt. > > If you drop code without first deprecating it, chances are it will > hurt someone. That's why having a deprecation period is the rule we > usually follow (most of the time :-)). Indeed. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] PEP 385: Formatting of Hg checkin notifications
Following the python-checkins list, I get to see both the current SVN notifications and the Hg notifications from Tarek's pushes into the distutils repository. I realised today that there is one key reason as to why the latter strikes me as a big wall of unintelligible text, while I find the SVN notification quite easy to read: vertical whitespace. The SVN notification uses vertical whitespace to separate out the log message and the list of files affected clearly from the rest of the header fields. It makes it *really* easy to see at a glance what the checkin was about and which files were affected. For the Hg notification, both of these fields are embedded in a big header block along with all the other fields, so it is quite difficult to make out the same information. It would be really nice if the formatting could be improved for the email notifications on the Hg side when we adopt it for the main CPython repository. The changes would be to: - add a blank line before and after the summary field - add a carriage return between the header and content for the summary field and the files field - indent the list of files by two spaces and use a carriage return rather than a comma to separate named files I've included an example below based on one of Tarek's recent pushes: Current Hg notification header and start of first diff: tarek.ziade pushed 7ebf14ab2840 to distutils2: http://hg.python.org/distutils2/rev/7ebf14ab2840 changeset: 816:7ebf14ab2840 tag: tip user:Tarek Ziade date:Sat Nov 13 12:40:33 2010 +0100 summary: compiler_type -> name files: distutils2/compiler/__init__.py, distutils2/compiler/bcppcompiler.py, distutils2/compiler/ccompiler.py, distutils2/compiler/cygwinccompiler.py, distutils2/compiler/msvc9compiler.py, distutils2/compiler/msvccompiler.py, distutils2/compiler/unixccompiler.py, distutils2/tests/test_config.py diff --git a/distutils2/compiler/__init__.py b/distutils2/compiler/__init__.py --- a/distutils2/compiler/__init__.py +++ b/distutils2/compiler/__init__.py @@ -13,7 +13,7 @@ Proposed change to separate out summary and files fields: tarek.ziade pushed 7ebf14ab2840 to distutils2: http://hg.python.org/distutils2/rev/7ebf14ab2840 changeset: 816:7ebf14ab2840 tag: tip user:Tarek Ziade date:Sat Nov 13 12:40:33 2010 +0100 summary: compiler_type -> name files: distutils2/compiler/__init__.py distutils2/compiler/bcppcompiler.py distutils2/compiler/ccompiler.py distutils2/compiler/cygwinccompiler.py distutils2/compiler/msvc9compiler.py distutils2/compiler/msvccompiler.py distutils2/compiler/unixccompiler.py distutils2/tests/test_config.py diff --git a/distutils2/compiler/__init__.py b/distutils2/compiler/__init__.py --- a/distutils2/compiler/__init__.py +++ b/distutils2/compiler/__init__.py @@ -13,7 +13,7 @@ Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Stable buildbots
Antoine Pitrou writes: > (even though the Windows buildbots give > a rather unconventional meaning to the word "stability"). Nag, nag, nag :-) There's been a bit of an uptick in the past few weeks with hung python_d processes (not a new issue, but it ebbs and flows), so I'm going to try to pull together a monitor script this weekend to start killing them off automatically. Should at least get rid of some of the low hanging fruit that interferes with subsequent builds. -- David ___ 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] PEP 385: Formatting of Hg checkin notifications
On 11/13/2010 8:28 PM, Nick Coghlan wrote: Following the python-checkins list, I get to see both the current SVN notifications and the Hg notifications from Tarek's pushes into the distutils repository. I realised today that there is one key reason as to why the latter strikes me as a big wall of unintelligible text, while I find the SVN notification quite easy to read: vertical whitespace. The SVN notification uses vertical whitespace to separate out the log message and the list of files affected clearly from the rest of the header fields. It makes it *really* easy to see at a glance what the checkin was about and which files were affected. For the Hg notification, both of these fields are embedded in a big header block along with all the other fields, so it is quite difficult to make out the same information. It would be really nice if the formatting could be improved for the email notifications on the Hg side when we adopt it for the main CPython repository. The changes would be to: - add a blank line before and after the summary field - add a carriage return between the header and content for the summary field and the files field - indent the list of files by two spaces and use a carriage return rather than a comma to separate named files I've included an example below based on one of Tarek's recent pushes: Current Hg notification header and start of first diff: tarek.ziade pushed 7ebf14ab2840 to distutils2: http://hg.python.org/distutils2/rev/7ebf14ab2840 changeset: 816:7ebf14ab2840 tag: tip user:Tarek Ziade date:Sat Nov 13 12:40:33 2010 +0100 summary: compiler_type -> name files: distutils2/compiler/__init__.py, distutils2/compiler/bcppcompiler.py, distutils2/compiler/ccompiler.py, distutils2/compiler/cygwinccompiler.py, distutils2/compiler/msvc9compiler.py, distutils2/compiler/msvccompiler.py, distutils2/compiler/unixccompiler.py, distutils2/tests/test_config.py diff --git a/distutils2/compiler/__init__.py b/distutils2/compiler/__init__.py --- a/distutils2/compiler/__init__.py +++ b/distutils2/compiler/__init__.py @@ -13,7 +13,7 @@ Proposed change to separate out summary and files fields: tarek.ziade pushed 7ebf14ab2840 to distutils2: http://hg.python.org/distutils2/rev/7ebf14ab2840 changeset: 816:7ebf14ab2840 tag: tip user:Tarek Ziade date:Sat Nov 13 12:40:33 2010 +0100 summary: compiler_type -> name files: distutils2/compiler/__init__.py distutils2/compiler/bcppcompiler.py distutils2/compiler/ccompiler.py distutils2/compiler/cygwinccompiler.py distutils2/compiler/msvc9compiler.py distutils2/compiler/msvccompiler.py distutils2/compiler/unixccompiler.py distutils2/tests/test_config.py diff --git a/distutils2/compiler/__init__.py b/distutils2/compiler/__init__.py --- a/distutils2/compiler/__init__.py +++ b/distutils2/compiler/__init__.py @@ -13,7 +13,7 @@ Much better except possible for \n after 'summary:' -- Terry Jan Reedy ___ 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] unexpected traceback/stack behavior with chained exceptions (issue 1553375)
Issue 1553375 [1] proposes a patch to add an 'allframes' option to the traceback printing and formatting routines so that the full traceback from the top of the execution stack down to the exception is printed, instead of just from the point where the exception is caught down to the exception. This is useful when the reason you are capturing the traceback is to log it, and you have several different points in your application where you do such traceback logging. You often really want to know the entire stack in that case; logging only from the capture point down can lose important debugging information depending on how the application is structured. The patch seems to work well, except for one problem that I don't have enough CPython internals knowledge to understand. If the traceback we are printing has a chained traceback, the resulting full traceback shows the line that is printing the traceback instead of the line from the 'try' block. (It prints the expected line if there is no chained traceback). So, is this a failure in my understanding of how tracebacks are supposed to work, or a bug in how chained tracebacks are constructed? [1] http://bugs.python.org/issue1553375 -- R. David Murray www.bitdance.com ___ 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
