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*
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/
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!
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~
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
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.
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
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
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.
Hi,
I modified the Python documentaton (asyncio module) 6 days ago, and my
changes are not online yet:
http://docs.python.org/dev/library/asyncio-eventloop.html#running-subproces…
Is it a problem with the server generating the documentation?
By the way, would it be possible to regenerate the documentation at
each commit, or maybe every hours, instead of having to wait 24h to
see the modified documentation online?
Thanks.
Victor
