Mailman 3 June 2013 - Python-Dev

Classes with ordered namespaces
by Eric Snow June 27, 2013

June 27, 2013

There are two relevant class namespaces in this proposal: definition namespace and __dict__. Currently both are dicts. For class definition namespaces, I'd like to make the default an OrderedDict. With the implementation in issue16991, the change is trivial (basically 1-liners in 2 spots). This change would make it unnecessary to write a custom metaclass just for a __prepare__(). PEP 422 alleviates that problem somewhat. However, I expect OrderedDict is by far the most common type returned by __prepare__(), so having it be the default would proportionately reduce the need for people to write metaclasses or learn about the PEP 422 API. You may ask what is the point if they aren't using a metaclass. That leads to the other half of the proposal. Once I have a class, I'd like to know the definition order without needing a metaclass. Unfortunately it's not as simple as using the C OrderedDict (issue16991 again) for tp_dict, etc. That change is actually pretty trivial. However, it causes problems because the concrete C API (PyDict_*) doesn't play nice with subclasses and the concrete API is used on class __dict__ all over the place. The alternative I propose is to add __definition_order__ or similar to classes. It would be a list of the names from the definition namespace, in definition order (making use of the new default there). Having a class's __dict__ be ordered isn't important if the definition order is available somewhere. Again, using the C OrderedDict, the change to add __definition_order__ is pretty trivial. FWIW, Guido already expressed some approval[1]. -eric [1] http://mail.python.org/pipermail/python-ideas/2013-February/019704.html

4 7

Re: [Python-Dev] [Python-checkins] peps: Reject PEP 315.
by R. David Murray June 27, 2013

June 27, 2013

On Wed, 26 Jun 2013 17:39:07 +0200, lukasz.langa <python-checkins(a)python.org> wrote: > - Deferred; see > + Rejected; see > + http://mail.python.org/pipermail/python-ideas/2013-June/021610.html > + > + This PEP has been deferred since 2006; see > http://mail.python.org/pipermail/python-dev/2006-February/060718.html > > Subsequent efforts to revive the PEP in April 2009 did not > meet with success because no syntax emerged that could > - compete with a while-True and an inner if-break. > + compete with the following form: > > - A syntax was found for a basic do-while loop but it found > - had little support because the condition was at the top: > + while True: > + <setup code> > + if not <condition>: > + break > + <loop body> > > - do ... while <cond>: > - <loop body> > + Users of the language are advised to use that form when a do-while > + loop would have been appropriate. Why delete the information about what was found wanting? --David

3 3

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod
by Antoine Pitrou June 25, 2013

June 25, 2013

On Fri, 14 Jun 2013 07:06:49 +0200 (CEST) raymond.hettinger <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/5accb0ac8bfb > changeset: 84116:5accb0ac8bfb > branch: 2.7 > parent: 84095:ca8e86711403 > user: Raymond Hettinger <python(a)rcn.com> > date: Fri Jun 14 01:06:33 2013 -0400 > summary: > Fix comment blocks. Adjust blocksize to a power-of-two for better divmod computations. Is there any rationale for changing the heuristic from "fits in a whole number of cachelines" to "allows fast division by the blocksize"? I personally would prefer if such changes were justified a bit more than by a one-liner changeset message without any corresponding open issue. Regards Antoine.

12 26

Re: [Python-Dev] [Python-checkins] cpython (3.3): Add -b and -X options to python man page.
by Brett Cannon June 25, 2013

June 25, 2013

On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran < python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/dfead0696a71 > changeset: 84224:dfead0696a71 > branch: 3.3 > parent: 84221:0113247f894b > user: Senthil Kumaran <senthil(a)uthcode.com> > date: Wed Jun 19 22:19:46 2013 -0500 > summary: > Add -b and -X options to python man page. > Patch contributed by Corey Brune. > > files: > Misc/python.man | 22 ++++++++++++++++++---- > 1 files changed, 18 insertions(+), 4 deletions(-) > > > diff --git a/Misc/python.man b/Misc/python.man > --- a/Misc/python.man > +++ b/Misc/python.man > @@ -11,6 +11,9 @@ > .B \-B > ] > [ > +.B \-b > +] > +[ > .B \-d > ] > [ > @@ -23,14 +26,14 @@ > .B \-i > ] > [ > -.B \-m > +.B \-m > .I module-name > ] > -[ > -.B \-q > -] > .br > [ > +.B \-q > +] > +[ > .B \-O > ] > [ > @@ -60,6 +63,10 @@ > .B \-x > ] > [ > +[ > +.B \-X > +.I option > +] > .B \-? > ] > .br > @@ -105,6 +112,10 @@ > .I .py[co] > files on import. See also PYTHONDONTWRITEBYTECODE. > .TP > +.B \-b > +Issue warnings about str(bytes_instance), str(bytearray_instance) > +and comparing bytes/bytearray with str. (-bb: issue errors) > +.TP > .BI "\-c " command > Specify the command to execute (see next section). > This terminates the option list (following options are passed as > @@ -243,6 +254,9 @@ > field matches the line number, where zero matches all line numbers and > is thus equivalent to an omitted line number. > .TP > +.BI "\-X " option > +Set implementation specific option. > Should probably be "Set the implementation-specific option." > +.TP > .B \-x > Skip the first line of the source. This is intended for a DOS > specific hack only. Warning: the line numbers in error messages will > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > >

9 11

Re: [Python-Dev] [Python-checkins] cpython: Issue #18081: Workaround "./python -m test_idle test_logging" failure
by Brett Cannon June 25, 2013

June 25, 2013

This fix is still not correct as warnings.formatwarning should not be overridden, only showwarning can be. On Jun 24, 2013 6:18 PM, "victor.stinner" <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/2a9e1eb3719c > changeset: 84330:2a9e1eb3719c > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Tue Jun 25 00:17:37 2013 +0200 > summary: > Issue #18081: Workaround "./python -m test_idle test_logging" failure > > "import idlelib" should not install hooks on the warning modules, hooks > should > only be installed when IDLE is started. > > files: > Lib/idlelib/PyShell.py | 5 +++-- > Lib/idlelib/run.py | 4 +++- > 2 files changed, 6 insertions(+), 3 deletions(-) > > > diff --git a/Lib/idlelib/PyShell.py b/Lib/idlelib/PyShell.py > --- a/Lib/idlelib/PyShell.py > +++ b/Lib/idlelib/PyShell.py > @@ -61,7 +61,6 @@ > lineno, line=line)) > except OSError: > pass ## file (probably __stderr__) is invalid, warning > dropped. > - warnings.showwarning = idle_showwarning > def idle_formatwarning(message, category, filename, lineno, > line=None): > """Format warnings the IDLE way""" > s = "\nWarning (from warnings module):\n" > @@ -73,7 +72,6 @@ > s += " %s\n" % line > s += "%s: %s\n>>> " % (category.__name__, message) > return s > - warnings.formatwarning = idle_formatwarning > > def extended_linecache_checkcache(filename=None, > orig_checkcache=linecache.checkcache): > @@ -1425,6 +1423,9 @@ > def main(): > global flist, root, use_subprocess > > + warnings.showwarning = idle_showwarning > + warnings.formatwarning = idle_formatwarning > + > use_subprocess = True > enable_shell = False > enable_edit = False > diff --git a/Lib/idlelib/run.py b/Lib/idlelib/run.py > --- a/Lib/idlelib/run.py > +++ b/Lib/idlelib/run.py > @@ -40,7 +40,6 @@ > s += " %s\n" % line > s += "%s: %s\n" % (category.__name__, message) > return s > - warnings.formatwarning = idle_formatwarning_subproc > > > tcl = tkinter.Tcl() > @@ -82,6 +81,9 @@ > global exit_now > global quitting > global no_exitfunc > + > + warnings.formatwarning = idle_formatwarning_subproc > + > no_exitfunc = del_exitfunc > #time.sleep(15) # test subprocess not responding > try: > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > >

1 0

Re: [Python-Dev] [Python-checkins] cpython (3.3): Add -b and -X options to python man page.
by Maciej Fijalkowski June 25, 2013

June 25, 2013

On Mon, Jun 24, 2013 at 10:56 PM, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > On Mon, 24 Jun 2013 16:43:15 -0400 > "R. David Murray" <rdmurray(a)bitdance.com> wrote: >> On Mon, 24 Jun 2013 22:14:46 +0200, Maciej Fijalkowski <fijall(a)gmail.com> wrote: >> > On Sun, Jun 23, 2013 at 6:14 PM, R. David Murray <rdmurray(a)bitdance.com> wrote: >> > > On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski <fijall(a)gmail.com> wrote: >> > >> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon <brett(a)python.org> wrote: >> > >> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran >> > >> > <python-checkins(a)python.org> wrote: >> > >> >> .TP >> > >> >> +.BI "\-X " option >> > >> >> +Set implementation specific option. >> > >> > >> > >> > >> > >> > Should probably be "Set the implementation-specific option." >> > >> >> > >> Is there anyone respecting this notation? (I know pypy does not, it >> > >> uses --jit and stuff) >> > > >> > > CPython does. We introduced it for ourselves, it is up to other >> > > implementations whether or not to use it, or use something else. >> > > >> > > --David >> > >> > you mean "CPython does not have any implementation-specific options"? >> > I would claim -O behavior should be implementation-specific since it's >> > nonsense in the optimizations sense, but other than that, it does not >> > seem that there is any -X options? >> >> There is one. -X faulthandler. I'm sure others would agree about >> -O, but that long predates -X. >> >> So, the idea is that -X *can* be used by other implementations for their >> own purposes, but there is certainly no requirement that they do so. >> Our promise is that anything CPython uses it for is something we don't >> expect other implementations to support. > > Yes, basically -X is a private namespace for every implementation to > use as it sees fit without fearing of conflicting with a future > cross-implementation option. > > Regards > > Antoine. I'm for one looking forward to the day where cpython conflicts on --jit ;-)

1 0

Re: [Python-Dev] [Python-checkins] cpython: Issue #9566: recv(), recvfrom(), send(), sendall() and sendto() methods
by Jeremy Kloth June 24, 2013

June 24, 2013

On Mon, Jun 24, 2013 at 3:48 PM, victor.stinner <python-checkins(a)python.org> wrote: > +#if defined(MS_WIN64) || defined(MS_WINDOWS) This test could be reduced to simply `#ifdef MS_WINDOWS`. See PC\pyconfig.h

2 1

Re: [Python-Dev] [Python-checkins] cpython: Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64
by Jeremy Kloth June 24, 2013

June 24, 2013

On Mon, Jun 24, 2013 at 3:33 PM, victor.stinner <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/6b4d279508a3 > changeset: 84325:6b4d279508a3 > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Mon Jun 24 23:31:48 2013 +0200 > summary: > Issue #9566: Fix a compiler warning in tupleiter_setstate() on Windows x64 > > files: > Objects/tupleobject.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > diff --git a/Objects/tupleobject.c b/Objects/tupleobject.c > --- a/Objects/tupleobject.c > +++ b/Objects/tupleobject.c > @@ -997,7 +997,7 @@ > static PyObject * > tupleiter_setstate(tupleiterobject *it, PyObject *state) > { > - long index = PyLong_AsLong(state); > + Py_ssize_t index = PyLong_AsLong(state); Actually, this will still lose data when state > MAX_INT (on Windows). It should be changed to PyLong_AsSssize_t(state) to ensure consistent behavior on all platforms. -- Jeremy Kloth

2 1

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #18277: Document quirks of multiprocessing queue.
by A.M. Kuchling June 24, 2013

June 24, 2013

On Mon, Jun 24, 2013 at 03:53:27PM +0200, richard.oudkerk wrote: > http://hg.python.org/cpython/rev/8dcc4e017d42 > + but should not cause any pratical difficulties -- you can always ^^ practical > + infinitessimal delay before the queue's :meth:`~Queue.empty` ^^ infinitesimal (or just "short") --amk

2 1

A type of out-of-range exception for %c
by Serhiy Storchaka June 23, 2013

June 23, 2013

Currently %c formatting raises OverflowError if an argument is out of range. >>> '%c' % 1114112 Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: %c arg not in range(0x110000) >>> '{:c}'.format(1114112) Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: %c arg not in range(0x110000) The same for PyUnicode_Format(), PyUnicode_FromFromat() and PyUnicode_FromFromatV() in C API. But chr() raises ValueError. >>> chr(1114112) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: chr() arg not in range(0x110000) And ValueError looks more suitable, because it is not really an overflow (limitation of the C language, or a C type). Can we change an exception type for %c formatting from OverflowError to ValueError?

3 2