Mailman 3 February 2014 - Python-Dev

PyPI offline, status is ok
by anatoly techtonik 10 Feb '14

10 Feb '14

http://status.python.org/ shows all green https://pypi.python.org/pypi/gazest shows Error 503 backend read error backend read error Guru Meditation: XID: 2792709923 ________________________________ Varnish cache server https://pypi.python.org/pypi/ shows XID: 4199593736 -- anatoly t.

2 2

Getting Introduced with the Community and Looking forward to Contribute to the Project as part of Gsoc 2014
by Nitika 09 Feb '14

09 Feb '14

Hi, Firstly I, Nitika would like to introduce myself to the developers of this commmunity. I am currently pursuing Computer Science and Engineering at Netaji Subhash Institute of Technology INDIA. I have been following the discussions on the mailing list for past few months. I had got an indepth knowledge of the tools used for the development of open source software. My skills include Programming languages: GNU C/C++, Python, Javascript, Version control systems Git/Github and SVN. I am also aware with many of the web development application tools and content management systems. I am an ambitous person willing to learn other technologies when need in future. I choose this organisation for the contribution as the work the community does looks very appealing and interesting to me and useful for the whole community. The skills used by the organisation for the development of open source software matches with my skills to much extent. I had installed the required necessary tools and setup the environment in my system needed for the contribution to open source software. I had got myself aware of the source to some extent and had forked on my github account. I had also read the contribution, development tutorial on the community webpage. I would like to seek the mentors help in the selection of the project for which the idea has been proposed for the Gsoc and someone is willing to mentor the project idea. I will highly appreciate with any kind of help, guidance from the mentors to help me move forward to contribute to the software starting off with some easy tasks and then moving levels higher so as to make a strong proposal for the upcoming Google Summer of Code 2014. [1] Github : https://github.com/NitikaAgarwal [2] IRC : nitika18 *--Nitika Agarwal*

2 1

The docstring hack for signature information has to go
by Larry Hastings 09 Feb '14

09 Feb '14

A quick summary of the context: currently in CPython 3.4, a builtin function can publish its "signature" as a specially encoded line at the top of its docstring. CPython internally detects this line inside PyCFunctionObject.__doc__ and skips past it, and there's a new getter at PyCFunctionObject.__text_signature__ that returns just this line. As an example, the signature for os.stat looks like this: sig=($module, path, *, dir_fd=None, follow_symlinks=True) The convention is, if you have this signature, you shouldn't have your docstring start with a handwritten signature like 3.3 and before. help() on a callable displays the signature automatically if it can, so if you *also* had a handwritten signature, help() would show two signatures. That would look dumb. ----- So here's the problem. Let's say you want to write an extension that will work with Python 3.3 and 3.4, using the stable ABI. If you don't add this line, then in 3.4 you won't have introspection information, drat. But if you *do* add this line, your docstring will look mildly stupid in 3.3, because it'll have this unsightly "sig=(" line at the top. And it *won't* have a nice handwritten docstring. (And if you added both a sig= signature *and* a handwritten signature, in 3.4 it would display both. That would also look dumb.) I can't figure out any way to salvage this "first line of the docstring" approach. So I think we have to abandon it, and do this the hard way: extend the PyMethodDef structure. I propose three different variations. I prefer B, but I'm guessing Guido would prefer the YAGNI approach, which is A: A: We create a PyMethodDefEx structure with an extra field: "const char *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to the flags, indicating that this is an extended structure. When iterating over the PyMethodDefs, we know how far to advance the pointer based on this flag. B: Same as A, but we add three unused pointers (void *reserved1 etc) to PyMethodDefEx to give us some room to grow. C: Same as A, but we add two fields to PyMethodDefEx. The second new field identifies the "version" of the structure, telling us its size somehow. Like the lStructSize field of the OPENFILENAME structure in Win32. I suspect YAGNI. ----- But that only fixes part of the problem. Our theoretical extension that wants to be binary-compatible with 3.3 and 3.4 still has a problem: how can they support signatures? They can't give PyMethodDefEx structures to 3.3, it will blow up. But if they don't use PyMethodDefEx, they can't have signatures. Solution: we write a function (which users would have to copy into their extension) that gives a PyMethodDefEx array to 3.4+, but converts it into a PyMethodDef array for 3.3. The tricky part there: what do we do about the docstring? The convention for builtins is to have the first line(s) contain a handwritten signature. But you *don't* want that if you provide a signature, because help() will read that signature and automatically render this first line for you. I can suggest four options here, and of these I like P best: M: Don't do anything. Docstrings with real signature information and a handwritten signature in the docstring will show two signatures in 3.4+, docstrings without any handwritten signature won't display their signature in help in 3.3. (Best practice for modules compiled for 3.4+ is probably: skip the handwritten signature. Users would have to do without in 3.3.) N: Leave the handwritten signature in the docstring, then when registering for 3.4+ add a second flag called METH_33_COMPAT that means "when displaying help for this function, don't automatically generate that first line." O: Have the handwritten signature in the docstring. When registering the function for 3.3, have the PyMethodDef docstring point to the it starting at the signature. When registering the function for 3.4+, have the docstring in the PyMethodDefEx point to the first byte after the handwritten signature. Note that automatically skipping the signature with a heuristic is mildly complicated, so this may be hard to get right. P: Have the handwritten signature in the docstring, and have separate static PyMethodDef and PyMethodDefEx arrays. The PyMethodDef docstring points to the docstring like normal. The PyMethodDefEx docstring field points to the first byte after the handwritten signature. This makes the registration "function" very simple: if it's 3.3 or before, use the PyMethodDef array, if it's 3.4+ use the PyMethodDefEx array. (Argument Clinic could theoretically automate coding some or all of this.) It's late and my brain is only working so well. I'd be interested in other approaches if people can suggest something good. Sorry about the mess, //arry/

14 30

Google Summer of Code 2014: Looking for core python mentors!
by Terri Oda 07 Feb '14

07 Feb '14

For anyone who completely isn't familiar with this: Google Summer of Code is a program where Google pays students to work on open source projects for the summer. The motto goes: "Flip bits, not burgers." Google Summer of Code applications are open for mentoring organizations, and I've already put in Python's application. You can get more info here: https://wiki.python.org/moin/SummerOfCode/2014 What I'd like to know is if anyone's got any good ideas for core python projects this year and are interested in mentoring. We always have lots of students who'd like to work on Python, but right now we don't have any mentors who are available and interested in helping students make contributions to the language (We do, however, have mentors for various python sub-projects). Let me know if this might be interesting to you. I'm happy to answer any questions, and I've got experienced mentors who aren't core python devs but who'd be willing to pair up so you wouldn't have to go it alone, just let me know! Terri PS - I'm also looking for new sub-projects and other mentors -- just ask if you want to take part this year!

1 0

ReST documents
by Ethan Furman 06 Feb '14

06 Feb '14

My apologies if this is a stupid question (actually, two stupid questions! ;) , but: - is there someplace I can look to see what all the meta commands mean? Things like :class: or .. index:: pair: class; constructor - when I click on a link (using FireFox 16.0.1) instead of showing the title of that section (such as IntEnum or object.__init__) it shows the paragraph immediately following. I think it would be more helpful to show the title as well. Is this an issue with how we are creating the docs, or with FireFox? -- ~Ethan~

2 2

Re: [Python-Dev] [Python-checkins] cpython: Close #20053: ignore default pip config settings
by Jeremy Kloth 05 Feb '14

05 Feb '14

On Tue, Feb 4, 2014 at 6:03 AM, nick.coghlan <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/1b8ba1346e67 > changeset: 88955:1b8ba1346e67 > user: Nick Coghlan <ncoghlan(a)gmail.com> > date: Tue Feb 04 23:02:36 2014 +1000 > summary: > Close #20053: ignore default pip config settings > > ensurepip now sets PIP_CONFIG_FILE to os.devnull before > import pip from the wheel file. This also ensures venv > ignores the default settings when bootstrapping pip. > > files: > Lib/ensurepip/__init__.py | 9 ++++-- > Lib/test/test_ensurepip.py | 16 +++++++++++ > Lib/test/test_venv.py | 37 +++++++++++++++++++------ > Misc/NEWS | 3 ++ > 4 files changed, 53 insertions(+), 12 deletions(-) This changeset caused the Windows buildbots to go red. Excerpt from one of the logs: ====================================================================== FAIL: test_with_pip (test.test_venv.EnsurePipTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 349, in test_with_pip self.assertEqual(err, "") AssertionError: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp[57 chars]\r\n' != '' - C:\Users\Buildbot\AppData\Local\Temp\tmpkwelerus\Scripts\python_d.exe: No module named pip -- Jeremy Kloth

2 1

__doc__ regression
by Antoine Pitrou 05 Feb '14

05 Feb '14

Hello, Following the previous clinic thread, I realize that the latest signature improvements actually entail a regression in __doc__. Compare: $ ./python -c "print(dict.fromkeys.__doc__)" Returns a new dict with keys from iterable and values equal to value. $ python3.3 -c "print(dict.fromkeys.__doc__)" dict.fromkeys(S[,v]) -> New dict with keys from S and values equal to v. v defaults to None. As you see the signature string has vanished from the __doc__ contents. This means that any tool directly processing __doc__ attributes to generate (e.g.) automatic API docs will produce less useful docs. I think the signature should be restored, and a smarter way of reconciling __doc__ and the signature for help() should be found. Regards Antoine.

4 6

expat symbols should be namespaced in pyexpat (Issue19186 - no progress in four months)
by Lukas Vacek 04 Feb '14

04 Feb '14

Hi everyone, Just wondering if anyone has looked into http://bugs.python.org/issue19186- priority has been changed to critical four months ago but nothing has happened since. I think it would be nice to get this sorted before python3.4 release Cheers, Lucas

2 1

test whatever failed
by Milani Adelaide 04 Feb '14

04 Feb '14

Dear support, we tried to install Phyton-3.3.3 but we got some problems with "make test". Test whatever failed. We trid also "make testall" but we got: Ran 45 tests in 7.897s FAILED (failures=25, skipped=15) test test_gdb failed make: *** [testall] Errore 1 Please could you help us? Thanks Adelaide Adelaide Milani, PhD student Division of Comparative Biomedical Sciences. OIE/FAO and National Reference Laboratory for Avian Influenza and Newcastle Disease FAO Reference Centre for Rabies OIE Collaborating Centre for Infectious Diseases at the Human- Animal Interface Istituto Zooprofilattico Sperimentale delle Venezie Viale dell'Università, 10, 35020, Legnaro (Padova), Italy Tel: 0039 049 8084381 Fax 0039 049 8084360

2 1

BugFix for "time" native module in Python 2.7
by Виктор Щерба 03 Feb '14

03 Feb '14

Hi, guys! I have found a bug in module "time" function "sleep" in Python 2.7 under Windows XP / Server 2003 and lower. I fix this bug locally. But how could I send you hg patch or pull request or, maybe, commit to sandbox? P.S.: Sorry for my English :-) Best Regards, Victor Scherba, C++ developer.

6 5