Re: [Python-Dev] The docstring hack for signature information has to go
Am 03.02.14 15:43, schrieb Larry Hastings:
> 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.
D: Add a new type slot for method signatures. This would be a
tp_signature field, along with a new slot id Py_tp_signature. The
signature field itself could be
struct PyMethodSignature {
char *method_name;
char *method_signature;
};
Regards,
Martin
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docstring hack for signature information has to go
Am 05.02.2014 14:52, schrieb "Martin v. Löwis":
> Am 03.02.14 15:43, schrieb Larry Hastings:
>> 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.
>
> D: Add a new type slot for method signatures. This would be a
> tp_signature field, along with a new slot id Py_tp_signature. The
> signature field itself could be
>
> struct PyMethodSignature {
>char *method_name;
>char *method_signature;
> };
Mostly unrelated question while seeing the "char *" here: do we (or do we
want to) support non-ASCII names for functions implemented in C?
Georg
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docstring hack for signature information has to go
On Wed, Feb 5, 2014 at 11:04 AM, Georg Brandl wrote:
> Am 05.02.2014 14:52, schrieb "Martin v. Löwis":
> > Am 03.02.14 15:43, schrieb Larry Hastings:
> >> 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.
> >
> > D: Add a new type slot for method signatures. This would be a
> > tp_signature field, along with a new slot id Py_tp_signature. The
> > signature field itself could be
> >
> > struct PyMethodSignature {
> >char *method_name;
> >char *method_signature;
> > };
>
> Mostly unrelated question while seeing the "char *" here: do we (or do we
> want to) support non-ASCII names for functions implemented in C?
>
Extension modules names being non-ASCII being discussed in
http://bugs.python.org/issue20485
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Close #20053: ignore default pip config settings
On Tue, Feb 4, 2014 at 6:03 AM, nick.coghlan wrote: > http://hg.python.org/cpython/rev/1b8ba1346e67 > changeset: 88955:1b8ba1346e67 > user:Nick Coghlan > 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 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Close #20053: ignore default pip config settings
On 6 Feb 2014 05:27, "Jeremy Kloth" wrote: > > On Tue, Feb 4, 2014 at 6:03 AM, nick.coghlan wrote: > > http://hg.python.org/cpython/rev/1b8ba1346e67 > > changeset: 88955:1b8ba1346e67 > > user:Nick Coghlan > > 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 Yeah, I noticed that yesterday :( I already reopened the issue, and flagged it as affecting the buildbots. Unfortunately, the only idea I've had for a possible culprit turned out not to be the problem (I added a separate test specifically to check the relevant cross-platform assumption, and that passed on Windows, but this test still failed) See the last few comments on http://bugs.python.org/issue20053 for details. Cheers, Nick. > > -- > Jeremy Kloth ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docstring hack for signature information has to go
On 02/05/2014 05:52 AM, "Martin v. Löwis" wrote:
D: Add a new type slot for method signatures. This would be a
tp_signature field, along with a new slot id Py_tp_signature. The
signature field itself could be
struct PyMethodSignature {
char *method_name;
char *method_signature;
};
That should work too, though we'd also have to add a md_signature field
to module objects.
It would probably be best to merge the signature into the callable
object anyway. Otherwise we'd have to go look up the signature using
__name__ and __self__ / __objclass__ on demand. Maybe that isn't such a
big deal, but it gets a little worse: as far as I can tell, there's no
attribute on a type object one can use to find the module it lives in.
So in this situation:
>>> import _pickle
>>> import inspect
>>> inspect.signature(_pickle.Pickler)
How could inspect.signature figure out that the "Pickler" type object
lives in the "_pickle" module? My best guess: parsing the __qualname__,
which is pretty ugly.
Also, keeping the signature as a reasonably-human-readable preface to
the docstring means that, if we supported this for third-party modules,
they could be binary ABI compatible with 3.3 and still have something
approximating the hand-written signature at the top of their docstring.
Cheers,
//arry/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
