Mailman 3 March 2013 - Python-Dev

Re: [Python-Dev] [Python-checkins] cpython: ../bug-fixes/http_error_interface/.hg/last-message.txt
by Senthil Kumaran March 19, 2013

March 19, 2013

Looks like I used hg commit -m /path/to/.hg/last-message.txt instead of hg commit -l /path/to/.hg/last-message.txt I have amended it, merged it and pushed it again. On Tue, Mar 19, 2013 at 12:04 PM, senthil.kumaran <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/4f2080e9eee2 > changeset: 82765:4f2080e9eee2 > parent: 82763:4c6463b96a2c > user: Senthil Kumaran <senthil(a)uthcode.com> > date: Tue Mar 19 12:07:43 2013 -0700 &… [View More]gt; summary: > ../bug-fixes/http_error_interface/.hg/last-message.txt > > files: > Lib/test/test_urllib2.py | 39 +++++++++++++-------------- > 1 files changed, 19 insertions(+), 20 deletions(-) > > > diff --git a/Lib/test/test_urllib2.py b/Lib/test/test_urllib2.py > --- a/Lib/test/test_urllib2.py > +++ b/Lib/test/test_urllib2.py > @@ -1387,6 +1387,10 @@ > > class MiscTests(unittest.TestCase): > > + def opener_has_handler(self, opener, handler_class): > + self.assertTrue(any(h.__class__ == handler_class > + for h in opener.handlers)) > + > def test_build_opener(self): > class MyHTTPHandler(urllib.request.HTTPHandler): pass > class FooHandler(urllib.request.BaseHandler): > @@ -1439,10 +1443,22 @@ > self.assertEqual(b"1234567890", request.data) > self.assertEqual("10", request.get_header("Content-length")) > > + def test_HTTPError_interface(self): > + """ > + Issue 13211 reveals that HTTPError didn't implement the URLError > + interface even though HTTPError is a subclass of URLError. > > - def opener_has_handler(self, opener, handler_class): > - self.assertTrue(any(h.__class__ == handler_class > - for h in opener.handlers)) > + >>> msg = 'something bad happened' > + >>> url = code = fp = None > + >>> hdrs = 'Content-Length: 42' > + >>> err = urllib.error.HTTPError(url, code, msg, hdrs, fp) > + >>> assert hasattr(err, 'reason') > + >>> err.reason > + 'something bad happened' > + >>> assert hasattr(err, 'headers') > + >>> err.headers > + 'Content-Length: 42' > + """ > > class RequestTests(unittest.TestCase): > > @@ -1514,23 +1530,6 @@ > req = Request(url) > self.assertEqual(req.get_full_url(), url) > > -def test_HTTPError_interface(): > - """ > - Issue 13211 reveals that HTTPError didn't implement the URLError > - interface even though HTTPError is a subclass of URLError. > - > - >>> msg = 'something bad happened' > - >>> url = code = fp = None > - >>> hdrs = 'Content-Length: 42' > - >>> err = urllib.error.HTTPError(url, code, msg, hdrs, fp) > - >>> assert hasattr(err, 'reason') > - >>> err.reason > - 'something bad happened' > - >>> assert hasattr(err, 'headers') > - >>> err.headers > - 'Content-Length: 42' > - """ > - > def test_main(verbose=None): > from test import test_urllib2 > support.run_doctest(test_urllib2, verbose) > > -- > Repository URL: http://hg.python.org/cpython > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > [View Less]

1 0

Re: [Python-Dev] [Python-checkins] peps: New DSL syntax and slightly changed semantics for the Argument Clinic DSL.
by Stefan Krah March 19, 2013

March 19, 2013

[PEP 436 revised syntax] While I like the syntax better and appreciate the option to condense the function declaration I still fear that the amount of implicitness will distract from what is important: programming in C. This applies especially if people start declaring converters using the [python] feature. So I hope that at least converters can be declared statically in a header file, like I suggested in PEP 437. A couple of comments: > As of CPython 3.3, builtin functions nearly … [View More]always parse their arguments > with one of two functions: the original ``PyArg_ParseTuple()``, [1]_ and > the more modern ``PyArg_ParseTupleAndKeywords()``. [2]_ The former > only handles positional parameters; the latter also accommodates keyword > and keyword-only parameters, and is preferred for new code. What is the source for this? I seem to remember a discussion on python-ideas (but cannot find it now) where some developers preferred non-keyword functions for some use cases. For example it's strange to write div(x=10, y=3), or worse, div(y=3, x=10). Using positional-only arguments prevents this "feature". > /*[clinic] > os.stat as os_stat_fn -> stat result > > path: path_t(allow_fd=1) > Path to be examined; can be string, bytes, or open-file-descriptor int. I do not see where the C initialization or the cleanup are specified. Are they part of the converter specification? > /*[clinic] > curses.window.addch > > [ > x: int > X-coordinate. > > y: int > Y-coordinate. > ] The parameters appear to be in the wrong order. > The return annotation is also optional. If skipped, the arrow ("``->``") > must also be omitted. Why is it optional? Aren't type annotations important? > Clinic will ship with a number of built-in converters; new converters can > also be added dynamically. How are the converters specified? Inside the preprocessor source? Are initialization and cleanup part of the specification, e.g. is a converter represented by a class? I would prefer if the converters were in a header file, like I suggested in PEP 437. Any tool can read such a file and custom converters can be redeclared above their definition. > The default value is dynamically assigned, "live" in the generated C code, > and although it's specified as a Python value, it's translated into a native > C value in the generated C code. Few default values are permitted, owing to > this manual translation step. I think there should be a table that lists which values are converted and what the result of the conversion is. > ``[`` > Establishes the start of an optional "group" of parameters. > Note that "groups" may nest inside other "groups". > See `Functions With Positional-Only Parameters`_ below. I don't quite understand the terminology: Functions with the ``/`` are also "positional-only". Why not reserve this syntax exclusively for the legacy left-and-right optional case? > ``/`` > This hints to Argument Clinic that this function is performance-sensitive, > and that it's acceptable to forego supporting keyword parameters when parsing. > (In early implementations of Clinic, this will switch Clinic from generating > code using ``PyArg_ParseTupleAndKeywords`` to using ``PyArg_ParseTuple``. > The hope is that in the future there will be no appreciable speed difference, > rendering this syntax irrelevant and deprecated but harmless.) Here I would use "positional-only" and mention that the slash plays essentially the same role as the vertical bar in the existing syntax. If this isn't the intention, then I simply did not understand the paragraph. > types > > A list of strings representing acceptable Python types for this object. > There are also four strings which represent Python protocols: I don't quite follow: Aren't input types always specified by the converter function? > Argument Clinic also permits embedding Python code inside C files, which > is executed in-place when Argument Clinic processes the file. Embedded code > looks like this: The example in posixmodule.c takes up a lot of space and from the perspective of auditing the effects it's a little like following a longjmp. Stefan Krah [View Less]

6 12

Tarfile CLI
by Serhiy Storchaka March 19, 2013

March 19, 2013

There is a proposition to add a command line interface to tarfile module. It will be useful on platforms where tar is not included in the base system. The question is about interface. Should it be a subset of tar options (-t as --extract, -t as --list, -f to specify an archive name) or be similar to the zipfile module interface (-e as --extract, -l as --list, the first positional parameter is an archive name)? There are different opinions.

1 1

newbuffer support in python 2.7
by Kristján Valur Jónsson March 18, 2013

March 18, 2013

Hi python dev. I have two languishing defects regarding 2.7 and how buffer support isn't complete there. http://bugs.python.org/issue10211 http://bugs.python.org/issue10212 In both cases, the new style buffer support is incomplete, and the patches close usability holes having to do with memoryview objects. It was suggested to me that I put it to python-dev to decide if we should consider this a bug to be fixed or not, and hopefully get a consensus before 2.7.4 freeze. I have been running a … [View More]

1 0

can't assign to function call
by Neal Becker March 18, 2013

March 18, 2013

def F(x): return x x = 2 F(x) = 3 F(x) = 3 SyntaxError: can't assign to function call Do we really need this restriction? There do exist other languages without it.

10 11

Re: [Python-Dev] [Python-checkins] peps: Update for 436, explicitly supporting positional parameters forever, amen.
by Nick Coghlan March 18, 2013

March 18, 2013

On Mon, Mar 18, 2013 at 1:47 AM, larry.hastings <python-checkins(a)python.org> wrote: > Notes / TBD > =========== > > +* The DSL currently makes no provision for specifying per-parameter > + type annotations. This is something explicitly supported in Python; > + it should be supported for builtins too, once we have reflection support. > + > + It seems to me that the syntax for parameter lines--dictated by > + Guido--suggests conversion functions are … [View More]

2 1

[PEP 437] A DSL for specifying signatures, annotations and argument converters
by Stefan Krah March 18, 2013

March 18, 2013

This PEP hasn't been announced yet, so here's a short notice for all people (like myself) who are not at PyCon. This is the counter proposal for the argument parsing DSL from PEP 436: http://www.python.org/dev/peps/pep-0437/ Both PEPs were discussed at PyCon. The state of affairs is that a compromise is being worked upon and will be published by Larry in a revised PEP. Stefan Krah

3 2

Status of XML fixes
by Christian Heimes March 18, 2013

March 18, 2013

Hello, I like to give an update on the XML vulnerability fixes. Brett has asked me a couple of days ago but I haven't had time to answer. I was/am busy with my daily job. Any attempt to fix the XML issues *will* change the behavior of the library and result into an incompatibility with older releases. Benjamin doesn't want to change the behavior of our XML libraries. IIRC Georg and Barry are +0. I think that we should keep the current and unsafe settings as default and add a simmple API to … [View More]

7 10

Re: [Python-Dev] [Python-checkins] peps: Update for 436, explicitly supporting positional parameters forever, amen.
by Stefan Krah March 18, 2013

March 18, 2013

larry.hastings <python-checkins(a)python.org> wrote: > + Establishes that all the *proceeding* arguments are > + positional-only. For now, Argument Clinic does not > + support functions with both positional-only and > + non-positional-only arguments; therefore, if ``/`` > + is specified for a function, currently it must always > + be after the last parameter. Also, Argument Clinic > + does not currently support default values for > + … [View More]

1 0

2.7.4 is inevitable
by Benjamin Peterson March 17, 2013

March 17, 2013

I am going to cut the 2.7.4 release branch next weekend (March 23, 24). Things which are breaking the buildbots at the point will be backed out. Owners of current release blockers will be poked, but nothing is going to hold up the release. The show must go on. Benjamin

1 0