Mailman 3 October 2011 - Python-Dev

Emit a BytesWarning on bytes filenames on Windows
by Victor Stinner Nov. 9, 2011

Nov. 9, 2011

Hi, I am not more conviced that raising a UnicodeEncodeError on unencodable characters is the right fix for the issue #13247. The problem with this solution is that you have to wait until an user get a UnicodeEncodeError. I have yet another proposition: emit a warning when a bytes filename is used. So it doesn't affect the default behaviour, but you can use -Werror to test if your program is fully Unicode compliant on Windows (without having to test invalid filenames). I don't know if a BytesWarning or a DeprecationWarning is more apropriate. It depends if we plan to drop support of bytes filenames on Windows later (in Python 3.5 or later). List of impacted functions: os._getfinalpathname(bytes) os._getfullpathname(bytes) os._isdir(bytes) os.access(bytes) os.chdir(bytes) os.chmod(bytes) os.getcwdb() os.link(bytes, bytes) os.listdir(bytes) os.lstat(bytes) os.mkdir(bytes) os.readlink(bytes) os.rename(bytes, bytes) os.rmdir(bytes) os.stat(bytes) os.symlink(bytes, bytes) os.unlink(bytes) os.utime(bytes, time) Note: Unicode filenames are not affected by this change. For example, os.listdir(str) will not emit any warning. Victor

6 10

Packaging and binary distributions
by Paul Moore Nov. 8, 2011

Nov. 8, 2011

I'd like to reopen the discussions on how the new packaging module will handle/support binary distributions in Python 3.3. The previous thread (see http://mail.python.org/pipermail/python-dev/2011-October/113956.html) included a lot of good information and discussion, but ultimately didn't reach any firm conclusions. First question - is this a Windows only problem, or do Unix/MacOS users want binary support? My feeling is that it's not an issue for them, at least not enough that anyone has done anything about it in the past, so I'll focus on Windows here. Second question - is there a problem at all? For the majority of Windows users, I suspect not. The existing bdist_wininst and bdist_msi formats have worked fine for a long time, offer Windows integration and a GUI installer, and in the case of MSI offer options for integrating with corporate distribution policies that some users consider significant, if not essential. (Binary eggs are a third, and somewhat odd, case - a number of projects have started distributing binary eggs, but I don't know what benefits they have over bdist_wininst in particular, as easy_install will read bdist_wininst installers. Perhaps a setuptools/distribute user could comment. For now I'll assume that binary eggs will slowly go away as packaging gets more widely adopted). So that leaves a minority who (1) prefer integration with packaging, (2) need to work with virtual environments or custom local builds, (3) need binary extensions in some or all of their environments and (4) don't want to have to build all the binaries they need from scratch. Given the scale of the issue, it seems likely that putting significant effort into addressing it is unwise. In particular, it seems unlikely that developers are going to move en masse to a new distribution format just to cater for this minority. On the other hand, for people who care, the fact that packaging (currently) offers no direct support for consuming binary distributions is a fairly obvious hole. And having to build from source just to install into a virtual environment could be a showstopper. The bdist_wininst format is relatively amenable to manipulation - it's little more than a zip file, after all. So writing 3rd party code to install the contents via packaging shouldn't be hard (I've done some proof of concept work, and it isn't :-)) Vinay's proposal to use the resource mechanism and some custom hooks would work, but I'd like to see a small amount of extra direct support added to packaging to make things cleaner. Also, if packaging supported plugins to recognise new distribution formats, this would make it possible to integrate the extra code seamlessly. The MSI format is a little more tricky, mainly because it is a more complex format and (as far as I can tell from a brief check) files are stored in the opaque CAB format, so the only way of getting data out is to do a temporary install somewhere. But I see no reason why that isn't achievable. So, my proposal is as follows: 1. I will write a 3rd party module to take bsist_wininst and bdist_msi modules and install them using packaging 2. Where packaging changes are useful to make installing binaries easier, I'll request them (by supplying patches) 3. I'll look at creating a format-handling plugin mechanism for packaging. If it's viable, I'll post patches 4. If it seems useful, my module could be integrated into the core packaging module I don't intend to do anything about a GUI, or modify the existing formats at all. These don't interest me, particularly, so I'll leave them to someone who has a clear picture of what they want in those areas, and the time to develop it. For 3.3 at least, I'd expect developers to continue distributing bdist_wininst or bdist_msi format files. We'll see what happens with binary eggs. Unix/MacOS users who care will need to propose something themselves. Does anyone have any comments? Paul.

10 25

genious hack in python
by Martin Goudreau Nov. 6, 2011

Nov. 6, 2011

Hello Dev Teem, Guido told me to send you this idea... Improving productivity is one of my Strength. Please check a very small module i'v made for improving the debugger traceback. See the pybettererror.py on sourceforge: http://pybettererror.sourceforge.net/projet.html It's hard to find something to complain about in python. This one was a too good idea to keep for myself. Thanks Martin Goudreau from Montreal

2 2

Code cleanups in stable branches?
by Éric Araujo Nov. 5, 2011

Nov. 5, 2011

Hi, > http://hg.python.org/cpython/rev/72de2ac8bb4f > branch: 2.7 > user: Petri Lehtinen <petri(a)digip.org> > date: Sun Oct 30 13:55:02 2011 +0200 > summary: > Avoid unnecessary recursive function calls (closes #10519) > http://hg.python.org/cpython/rev/0694ebb5db99 > branch: 2.7 > user: Jesus Cea <jcea(a)jcea.es> > date: Mon Oct 31 16:02:12 2011 +0100 > summary: > Closes #13283: removal of two unused variable in locale.py I thought that patches that clean up code but don’t fix actual bugs were not done in stable branches. Has this changed? (The first commit quoted above may be a performance fix, which would be okay IIRC.) Regards

5 6

Buildbot failures
by Antoine Pitrou Nov. 3, 2011

Nov. 3, 2011

Hello, There are currently a bunch of various buildbot failures on all 3 branches. I would remind committers to regularly take a look at the buildbots, so that these failures get solved reasonably fast. Regards Antoine.

5 5

Re: [Python-Dev] [Python-checkins] cpython (3.2): adjust braces a bit
by Eric V. Smith Nov. 1, 2011

Nov. 1, 2011

What's the logic for adding some braces, but removing others? On 10/19/2011 4:58 PM, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/9c79a25f4a8b > changeset: 73010:9c79a25f4a8b > branch: 3.2 > parent: 72998:99a9f0251924 > user: Benjamin Peterson <benjamin(a)python.org> > date: Wed Oct 19 16:57:40 2011 -0400 > summary: > adjust braces a bit > > files: > Objects/genobject.c | 9 ++++----- > 1 files changed, 4 insertions(+), 5 deletions(-) > > > diff --git a/Objects/genobject.c b/Objects/genobject.c > --- a/Objects/genobject.c > +++ b/Objects/genobject.c > @@ -232,8 +232,9 @@ > > /* First, check the traceback argument, replacing None with > NULL. */ > - if (tb == Py_None) > + if (tb == Py_None) { > tb = NULL; > + } > else if (tb != NULL && !PyTraceBack_Check(tb)) { > PyErr_SetString(PyExc_TypeError, > "throw() third argument must be a traceback object"); > @@ -244,9 +245,8 @@ > Py_XINCREF(val); > Py_XINCREF(tb); > > - if (PyExceptionClass_Check(typ)) { > + if (PyExceptionClass_Check(typ)) > PyErr_NormalizeException(&typ, &val, &tb); > - } > > else if (PyExceptionInstance_Check(typ)) { > /* Raising an instance. The value should be a dummy. */ > @@ -262,10 +262,9 @@ > typ = PyExceptionInstance_Class(typ); > Py_INCREF(typ); > > - if (tb == NULL) { > + if (tb == NULL) > /* Returns NULL if there's no traceback */ > tb = PyException_GetTraceback(val); > - } > } > } > else { > > > > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins

6 7

Re: [Python-Dev] cpython (2.7): test_protocol_sslv2(): Skip this test if ssl.PROTOCOL_SSLv2 is not
by Antoine Pitrou Oct. 31, 2011

Oct. 31, 2011

On Mon, 31 Oct 2011 19:09:01 +0100 barry.warsaw <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/1de4d92cd6a4 > changeset: 73258:1de4d92cd6a4 > branch: 2.7 > parent: 73253:7ce3b719306e > user: Barry Warsaw <barry(a)python.org> > date: Mon Oct 31 14:08:15 2011 -0400 > summary: > test_protocol_sslv2(): Skip this test if ssl.PROTOCOL_SSLv2 is not > defined (as is the case with Ubuntu 11.10). > > files: > Lib/test/test_ssl.py | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > > diff --git a/Lib/test/test_ssl.py b/Lib/test/test_ssl.py > --- a/Lib/test/test_ssl.py > +++ b/Lib/test/test_ssl.py > @@ -981,6 +981,8 @@ > @skip_if_broken_ubuntu_ssl > def test_protocol_sslv2(self): > """Connecting to an SSLv2 server with various client options""" > + if not hasattr(ssl, 'PROTOCOL_SSLv2'): > + raise unittest.SkipTest('No SSLv2 available') > if test_support.verbose: > sys.stdout.write("\n") > if not hasattr(ssl, 'PROTOCOL_SSLv2'): I'm not sure, but I've think you've just committed a no-op. (see http://hg.python.org/cpython/rev/5a080ebd311c) Regards Antoine.

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.7): Add a button to the code examples in the doc to show/hide the prompts and
by Éric Araujo Oct. 31, 2011

Oct. 31, 2011

Hi Ezio, > http://hg.python.org/cpython/rev/18bbfed9aafa > user: Ezio Melotti <ezio.melotti(a)gmail.com> > summary: > Add a button to the code examples in the doc to show/hide the prompts and output. Looks cool! I hope this will stop our use of two or three different styles for Python code in the docs (doctest-compatible vs. source-file-style vs. copy-paste-ready) and ultimately help make them doctest-compatible. > +$(document).ready(function() { > + /* Add a [>>>] button on the top-right corner of code samples to hide > + * the >>> and ... prompts and the output and thus make the code > + * copyable. */ I think it would be more user-friendly if the button/trigger would use real English text like “Hide prompts”/“Show prompts” rather than symbols. Cheers

2 1

Re: [Python-Dev] [Python-checkins] cpython (3.2): I should be someone
by Éric Araujo Oct. 31, 2011

Oct. 31, 2011

Hi, > http://hg.python.org/cpython/rev/6f56e81da8f6 > user: Florent Xicluna <florent.xicluna(a)gmail.com> > summary: > I should be someone Without quotation marks, that sounded like a philosophical commit :) Cheers

1 0

Re: [Python-Dev] cpython (merge 3.2 -> default): Fix the return value of set_discard (issue #10519)
by Antoine Pitrou Oct. 30, 2011

Oct. 30, 2011

On Sun, 30 Oct 2011 13:38:35 +0100 petri.lehtinen <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/f634102aca01 > changeset: 73204:f634102aca01 > parent: 73201:a5c4ae15b59d > parent: 73203:b643458a0108 > user: Petri Lehtinen <petri(a)digip.org> > date: Sun Oct 30 14:35:39 2011 +0200 > summary: > Fix the return value of set_discard (issue #10519) I get the following compiler warning here: Objects/setobject.c: In function ‘set_discard’: Objects/setobject.c:1909:24: attention : unused variable ‘result’ Regards Antoine.

1 0