Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
Am 04.12.2012 um 00:42 schrieb Gregory P. Smith : > * How would we convert all the builtins to use Clinic? I fear any > solution will involve some work by hand. Even if we can automate > big chunks of it, fully automating it would require parsing arbitrary > C. This seems like overkill for a one-shot conversion. > (Mark Shannon says he has some ideas.) > > A lot of hand work. Sprints at pycon. etc. Automating nice chunks of it > could be partially done for some easy cases such as things that only use > ParseTuple today. I don’t see this as a big problem. There’s always lots of people who want to get into Python hacking and don’t know where to start. These are easily digestible pieces that can be *reviewed in a timely manner*, thus ideal. We could even do some (virtual) sprint just on that. As for Larry: great approach, I’m impressed!___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #16455: On FreeBSD and Solaris, if the locale is C, the
Hi,
2012/12/4 Christian Heimes :
> Am 04.12.2012 03:23, schrieb victor.stinner:
>> http://hg.python.org/cpython/rev/c25635b137cc
>> changeset: 80718:c25635b137cc
>> parent: 80716:b845901cf702
>> user:Victor Stinner
>> date:Tue Dec 04 01:34:47 2012 +0100
>> summary:
>> Issue #16455: On FreeBSD and Solaris, if the locale is C, the
>> ASCII/surrogateescape codec is now used, instead of the locale encoding, to
>> decode the command line arguments. This change fixes inconsistencies with
>> os.fsencode() and os.fsdecode() because these operating systems announces an
>> ASCII locale encoding, whereas the ISO-8859-1 encoding is used in practice.
>>
>> files:
>> Include/unicodeobject.h |2 +-
>> Lib/test/test_cmd_line_script.py |9 +-
>> Misc/NEWS|6 +
>> Objects/unicodeobject.c | 24 +-
>> Python/fileutils.c | 240 +-
>> 5 files changed, 241 insertions(+), 40 deletions(-)
>
> ...
>
>> @@ -3110,7 +3110,8 @@
>> *surrogateescape = 0;
>> return 0;
>> }
>> -if (strcmp(errors, "surrogateescape") == 0) {
>> +if (errors == "surrogateescape"
>> +|| strcmp(errors, "surrogateescape") == 0) {
>> *surrogateescape = 1;
>> return 0;
>> }
>
> Victor, That doesn't look right. :) GCC is complaining about the code:
>
> Objects/unicodeobject.c: In function 'locale_error_handler':
> Objects/unicodeobject.c:3113:16: warning: comparison with string literal
> results in unspecified behavior [-Waddress]
Oh, I forgot to commit this change in a separated commit. It's a
micro-optimization.
PyUnicode_EncodeFSDefault() calls PyUnicode_EncodeLocale(unicode,
"surrogateescape"), and PyUnicode_DecodeFSDefaultAndSize() calls
PyUnicode_DecodeLocaleAndSize(s, size, "surrogateescape").
I chose to compare the address because I expect that GCC generates the
same address for "surrogateescape" in PyUnicode_EncodeFSDefault() and
in locale_error_handler(), comparing pointers is faster than comparing
the string content.
I remove this micro-optimization. The code path is only used during
Python startup, and I don't expect any real speedup.
> I'm also getting additional warnings in PyUnicode_Format().
>
> Objects/unicodeobject.c: In function 'PyUnicode_Format':
> Objects/unicodeobject.c:13782:8: warning: 'arg.sign' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> Objects/unicodeobject.c:13893:33: note: 'arg.sign' was declared here
> Objects/unicodeobject.c:13779:12: warning: 'str' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> Objects/unicodeobject.c:13894:15: note: 'str' was declared here
These members *are* initialized, but it's even hard to me (author of
this code) to check them. I rewrote how these members are initialized
to make the warnings quiet but also to simplify the code.
Thanks for the review!
Victor
PS: I hope that I really fixed the FreeBSD/Solaris issue :-p
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
Le Mon, 03 Dec 2012 14:29:35 -0800,
Larry Hastings a écrit :
>
>/*[clinic]
>dbm.open -> mapping
>basename=dbmopen
>
>const char *filename;
>The filename to open.
So how does it handle the fact that filename can either be a unicode
string or a fsencoding-encoded bytestring? And how does it do the right
encoding/decoding dance, possibly platform-specific?
>static char *_keywords[] = {"filename", "flags", "mode", NULL};
>
>if (!PyArg_ParseTupleAndKeywords(args, kwargs,
>"s|si", _keywords,
>&filename, &flags, &mode))
>return NULL;
I see, it doesn't :-)
> But the biggest unresolved question... is this all actually a terrible
> idea?
I like the idea, but it needs more polishing. I don't think the various
"duck types" accepted by Python can be expressed fully in plain C types
(e.g. you must distinguish between taking all kinds of numbers or only
an __index__-providing number).
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
Am 03.12.2012 23:29, schrieb Larry Hastings:
[...autogen some code from special comment strings...]
/*[clinic]
dbm.open -> mapping
basename=dbmopen
const char *filename;
The filename to open.
const char *flags="r";
How to open the file. "r" for reading, "w" for writing, etc.
int mode=0666;
default=0o666
If creating a new file, the mode bits for the new file
(e.g. os.O_RDWR).
Returns a database object.
[clinic]*/
Firstly, I like the idea. Even though this "autogenerate in-place" seems
a bit strange at first, I don't think it really hurts in practice. Also,
thanks for introducing me to the 'cog' tool, I think I'll use this now
and then!
This also brings me to a single question I have for your proposal: Why
did you create another DSL instead of using Python, i.e. instead of
using cog directly? Looking at the above, I could imagine this being
written like this instead:
/*[[[cog
import pycognize
with pycognize.function('dbmopen') as f:
f.add_param('self')
f.add_kwparam('filename',
doc='The filename to open',
c_type='char*')
f.add_kwparam('flags',
doc='How to open the file.'
c_type='char*',
default='r')
f.set_result('mapping')
]]]*/
//[[[end]]]
Cheers!
Uli
**
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Hans Robert Dapprich, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den
Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte
benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte
Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf
weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte
�nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht
verantwortlich.
**
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On 12/04/2012 04:10 AM, Ulrich Eckhardt wrote: This also brings me to a single question I have for your proposal: Why did you create another DSL instead of using Python, i.e. instead of using cog directly? Looking at the above, I could imagine this being written like this instead: Actually my original prototype was written using Cog. When I showed it to Guido at EuroPython, he suggested a DSL instead, as writing raw Python code for every single function would be far too wordy. I agree. //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
Larry Hastings, 03.12.2012 23:29: > Say there, the Python core development community! Have I got > a question for you! > > *ahem* > > Which of the following four options do you dislike least? ;-) > > 1) CPython continues to provide no "function signature" >objects (PEP 362) or inspect.getfullargspec() information >for any function implemented in C. I would love to see Cython generated functions look and behave completely like normal Python functions at some point, so this is the option I dislike most. > 2) We add new hand-coded data structures representing the >metadata necessary for function signatures for builtins. >Which means that, when defining arguments to functions in C, >we'd need to repeat ourselves *even more* than we already do. > > 3) Builtin function arguments are defined using some seriously >uncomfortable and impenetrable C preprocessor macros, which >produce all the various types of output we need (argument >processing code, function signature metadata, possibly >the docstrings too). > > 4) Builtin function arguments are defined in a small DSL; these >are expanded to code and data using a custom compile-time >preprocessor step. > [...] > * There's actually a fifth option, proposed by Brett Cannon. We > constrain the format of docstrings for builtin functions to make > them machine-readable, then generate the function signature objects > from that. But consider: generating *everything* in the signature > object may get a bit tricky (e.g. Parameter.POSITIONAL_ONLY), and > this might gunk up the docstring. Why not provide a constructor for signature objects that parses the signature from a string? For a signature like def func(int arg1, float arg2, ExtType arg3, *, object arg4=None) -> ExtType2: ... you'd just pass in this string: (arg1 : int, arg2 : float, arg3 : ExtType, *, arg4=None) -> ExtType2 or maybe prefixed by the function name, don't care. Might make it easier to pass it into the normal parser. For more than one alternative input type, use a tuple of types. For builtin types that are shadowed by C type names, pass "builtins.int" etc. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Mon, 2012-12-03 at 14:29 -0800, Larry Hastings wrote: [...snip compelling sales pitch...] I like the idea. As noted elsewhere, sane generated C code is much easier to step through in the debugger than preprocessor macros (though "sane" in that sentence is begging the question, I guess, but the examples you post look good to me). It's also seems cleaner to split the argument handling from the implementation of the function (iirc Cython already has an analogous split and can use this to bypass arg tuple creation). The proposal potentially also eliminates a source of bugs: mismatches between the format strings in PyArg_Parse* vs the underlying C types passed as varargs (which are a major pain for bigendian CPUs where int vs long screwups can really bite you). I got worried that this could introduce a bootstrapping issue (given that the clinic is implemented using python itself), but given that the generated code is checked in as part of the C source file, you always have the source you need to regenerate the interpreter. Presumably 3rd party extension modules could use this also, in which case the clinic tool could be something that could be installed/packaged as part of Python 3.4 ? [...snip...] > Big unresolved questions: > > * How would we convert all the builtins to use Clinic? I fear any >solution will involve some work by hand. Even if we can automate >big chunks of it, fully automating it would require parsing arbitrary >C. This seems like overkill for a one-shot conversion. >(Mark Shannon says he has some ideas.) Potentially my gcc python plugin could be used to autogenerate things. FWIW I already have Python code running inside gcc that can parse the PyArg_* APIs: http://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/libcpychecker/PyArg_ParseTuple.py Though my plugin runs after the C preprocessor has been run, so it may be fiddly to use this to autogenerate patches. Hope this is helpful Dave ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On 12/04/2012 01:08 AM, Antoine Pitrou wrote:
Le Mon, 03 Dec 2012 14:29:35 -0800,
Larry Hastings a écrit :
/*[clinic]
dbm.open -> mapping
basename=dbmopen
const char *filename;
The filename to open.
So how does it handle the fact that filename can either be a unicode
string or a fsencoding-encoded bytestring? And how does it do the right
encoding/decoding dance, possibly platform-specific?
[...]
I see, it doesn't :-)
If you compare the Clinic-generated code to the current implementation
of dbm.open (and all the other functions I've touched) you'll find the
"format units" specified to PyArg_Parse* are identical. Thus I assert
the replacement argument parsing is no worse (and no better) than what's
currently shipping in Python.
Separately, I contributed code that handles unicode vs bytes for
filenames in a reasonably cross-platform way; see "path_converter" in
Modules/posixmodule.c. (This shipped in Python 3.3.) And indeed, I
have examples of using "path_converter" with Clinic in my branch.
Along these lines, I've been contemplating proposing that Clinic
specifically understand "path" arguments, distinctly from other string
arguments, as they are both common and rarely handled correctly. My
main fear is that I probably don't understand all their complexities
either ;-)
Anyway, this is certainly something we can consider *improving* for
Python 3.4. But for now I'm trying to make Clinic an indistinguishable
drop-in replacement.
I like the idea, but it needs more polishing. I don't think the various
"duck types" accepted by Python can be expressed fully in plain C types
(e.g. you must distinguish between taking all kinds of numbers or only
an __index__-providing number).
Naturally I agree Clinic needs more polishing. But the problem you fear
is already solved. Clinic allows precisely expressing any existing
PyArg_ "format unit"** through a combination of the type of the
parameter and its "flags". The flags only become necessary for types
used by multiple format units; for example, s, z, es, et, es#, et#, y,
and y# all map to char *, so it's necessary to disambiguate by using the
"flags". The specific case you cite ("__index__-providing number") is
already unambiguous; that's n, mapped to Py_ssize_t. There aren't any
other format units that map to a Py_ssize_t, so we're done.
** Well, any format unit except w*. I don't handle it just because I
wasn't sure how best to do so.
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Mon, Dec 3, 2012 at 5:29 PM, Larry Hastings wrote: > > Say there, the Python core development community! Have I got > a question for you! > > *ahem* > > Which of the following four options do you dislike least? ;-) > > 1) CPython continues to provide no "function signature" >objects (PEP 362) or inspect.getfullargspec() information >for any function implemented in C. > > 2) We add new hand-coded data structures representing the >metadata necessary for function signatures for builtins. >Which means that, when defining arguments to functions in C, >we'd need to repeat ourselves *even more* than we already do. > > 3) Builtin function arguments are defined using some seriously >uncomfortable and impenetrable C preprocessor macros, which >produce all the various types of output we need (argument >processing code, function signature metadata, possibly >the docstrings too). > > 4) Builtin function arguments are defined in a small DSL; these >are expanded to code and data using a custom compile-time >preprocessor step. > > > All the core devs I've asked said "given all that, I'd prefer the > hairy preprocessor macros". But by the end of the conversation > they'd changed their minds to prefer the custom DSL. Maybe I'll > make a believer out of you too--read on! > > [snip] > * There's actually a fifth option, proposed by Brett Cannon. We > constrain the format of docstrings for builtin functions to make > them machine-readable, then generate the function signature objects > from that. But consider: generating *everything* in the signature > object may get a bit tricky (e.g. Parameter.POSITIONAL_ONLY), and > this might gunk up the docstring. > I should mention that I was one of the people Larry pitched this to and this fifth option was before I fully understood the extent the DSL supported the various crazy options needed to support all current use-cases in CPython. Regardless I fully support what Larry is proposing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Dec 04, 2012, at 11:47 AM, David Malcolm wrote: >As noted elsewhere, sane generated C code is much easier to step through >in the debugger than preprocessor macros (though "sane" in that sentence >is begging the question, I guess, but the examples you post look good to >me). And to me too. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, 04 Dec 2012 11:04:09 -0800 Larry Hastings wrote: > > Along these lines, I've been contemplating proposing that Clinic > specifically understand "path" arguments, distinctly from other string > arguments, as they are both common and rarely handled correctly. My > main fear is that I probably don't understand all their complexities > either ;-) > > Anyway, this is certainly something we can consider *improving* for > Python 3.4. But for now I'm trying to make Clinic an indistinguishable > drop-in replacement. > [...] > > Naturally I agree Clinic needs more polishing. But the problem you fear > is already solved. Clinic allows precisely expressing any existing > PyArg_ "format unit"** through a combination of the type of the > parameter and its "flags". Very nice then! Your work is promising, and I hope we'll see a version of it some day in Python 3.4 (or 3.4+k). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, Dec 4, 2012 at 11:35 AM, Antoine Pitrou wrote: > On Tue, 04 Dec 2012 11:04:09 -0800 > Larry Hastings wrote: >> >> Along these lines, I've been contemplating proposing that Clinic >> specifically understand "path" arguments, distinctly from other string >> arguments, as they are both common and rarely handled correctly. My >> main fear is that I probably don't understand all their complexities >> either ;-) >> >> Anyway, this is certainly something we can consider *improving* for >> Python 3.4. But for now I'm trying to make Clinic an indistinguishable >> drop-in replacement. >> > [...] >> >> Naturally I agree Clinic needs more polishing. But the problem you fear >> is already solved. Clinic allows precisely expressing any existing >> PyArg_ "format unit"** through a combination of the type of the >> parameter and its "flags". > > Very nice then! Your work is promising, and I hope we'll see a version > of it some day in Python 3.4 (or 3.4+k). +1 for getting this into 3.4. Does it need a PEP, or just a bug tracker item + code review? I think the latter is fine -- it's probably better not to do too much bikeshedding but just to let Larry propose a patch, have it reviewed and submitted, and then iterate. It's also okay if it is initially used for only a subset of extension modules (and even if some functions/methods can't be expressed using it yet). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
Hi, On Mon, Dec 3, 2012 at 3:42 PM, Gregory P. Smith wrote: > In fact allowing a version of Clinic to work stand alone as a > PyPI project and generate Python 2.7 and 3.2/3.3 extension module > boilerplate could would increase its adoption and improve the quality of > some existing extension modules that choose to use it. I agree: the same idea applies equally well to all existing 3rd-party extension modules, and does not depend on new CPython C API functions (so far), so Clinic should be released as a PyPI project too. A bientôt, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, Dec 4, 2012 at 4:17 PM, Guido van Rossum wrote: > On Tue, Dec 4, 2012 at 11:35 AM, Antoine Pitrou > wrote: > > On Tue, 04 Dec 2012 11:04:09 -0800 > > Larry Hastings wrote: > >> > >> Along these lines, I've been contemplating proposing that Clinic > >> specifically understand "path" arguments, distinctly from other string > >> arguments, as they are both common and rarely handled correctly. My > >> main fear is that I probably don't understand all their complexities > >> either ;-) > >> > >> Anyway, this is certainly something we can consider *improving* for > >> Python 3.4. But for now I'm trying to make Clinic an indistinguishable > >> drop-in replacement. > >> > > [...] > >> > >> Naturally I agree Clinic needs more polishing. But the problem you fear > >> is already solved. Clinic allows precisely expressing any existing > >> PyArg_ "format unit"** through a combination of the type of the > >> parameter and its "flags". > > > > Very nice then! Your work is promising, and I hope we'll see a version > > of it some day in Python 3.4 (or 3.4+k). > > +1 for getting this into 3.4. Does it need a PEP, or just a bug > tracker item + code review? I think the latter is fine -- it's > probably better not to do too much bikeshedding but just to let Larry > propose a patch, have it reviewed and submitted, and then iterate. > It's also okay if it is initially used for only a subset of extension > modules (and even if some functions/methods can't be expressed using > it yet). > I don't see a need for a PEP either; code review should be plenty since this doesn't change how the outside world views public APIs. And we can convert code iteratively so that shouldn't hold things up either. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, Dec 4, 2012 at 9:29 AM, Larry Hastings wrote: > To save you a little time, here's a preview of using Clinic for > dbm.open(). The stuff at the same indent as a declaration are > options; see the "clinic.txt" in the repo above for full documentation. > > /*[clinic] >... hand-written content ... > [clinic]*/ > > ... generated content ... > /*[clinic end:eddc886e542945d959b44b483258bf038acf8872]*/ > One thing I'm not entirely clear on. Do you run Clinic on a source file and it edits that file, or is it a step in the build process? Your description of a preprocessor makes me think the latter, but the style of code (eg the checksum) suggests the former. ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, 4 Dec 2012 16:45:54 -0500 Brett Cannon wrote: > > > > +1 for getting this into 3.4. Does it need a PEP, or just a bug > > tracker item + code review? I think the latter is fine -- it's > > probably better not to do too much bikeshedding but just to let Larry > > propose a patch, have it reviewed and submitted, and then iterate. > > It's also okay if it is initially used for only a subset of extension > > modules (and even if some functions/methods can't be expressed using > > it yet). > > > > I don't see a need for a PEP either; code review should be plenty since > this doesn't change how the outside world views public APIs. And we can > convert code iteratively so that shouldn't hold things up either. I think the DSL itself does warrant public exposure. It will be an element of the CPython coding style, if its use becomes widespread. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, Dec 4, 2012 at 4:48 PM, Antoine Pitrou wrote: > On Tue, 4 Dec 2012 16:45:54 -0500 > Brett Cannon wrote: > > > > > > +1 for getting this into 3.4. Does it need a PEP, or just a bug > > > tracker item + code review? I think the latter is fine -- it's > > > probably better not to do too much bikeshedding but just to let Larry > > > propose a patch, have it reviewed and submitted, and then iterate. > > > It's also okay if it is initially used for only a subset of extension > > > modules (and even if some functions/methods can't be expressed using > > > it yet). > > > > > > > I don't see a need for a PEP either; code review should be plenty since > > this doesn't change how the outside world views public APIs. And we can > > convert code iteratively so that shouldn't hold things up either. > > I think the DSL itself does warrant public exposure. It will be an > element of the CPython coding style, if its use becomes widespread. > That's what the issue will tease out, so this isn't going in without some public scrutiny. But going through python-ideas for this I think is a bit much. I mean we don't clear every change to PEP 7 or 8 with the public and that directly affects people as well in terms of coding style. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, 4 Dec 2012 16:54:27 -0500 Brett Cannon wrote: > On Tue, Dec 4, 2012 at 4:48 PM, Antoine Pitrou wrote: > > > On Tue, 4 Dec 2012 16:45:54 -0500 > > Brett Cannon wrote: > > > > > > > > +1 for getting this into 3.4. Does it need a PEP, or just a bug > > > > tracker item + code review? I think the latter is fine -- it's > > > > probably better not to do too much bikeshedding but just to let Larry > > > > propose a patch, have it reviewed and submitted, and then iterate. > > > > It's also okay if it is initially used for only a subset of extension > > > > modules (and even if some functions/methods can't be expressed using > > > > it yet). > > > > > > > > > > I don't see a need for a PEP either; code review should be plenty since > > > this doesn't change how the outside world views public APIs. And we can > > > convert code iteratively so that shouldn't hold things up either. > > > > I think the DSL itself does warrant public exposure. It will be an > > element of the CPython coding style, if its use becomes widespread. > > > > That's what the issue will tease out, so this isn't going in without some > public scrutiny. But going through python-ideas for this I think is a bit > much. I mean we don't clear every change to PEP 7 or 8 with the public and > that directly affects people as well in terms of coding style. Not necessarily python-ideas, but python-dev. (I hope we don't need a separate clinic-dev mailing-list, although it certainly sounds funny) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Dec 04, 2012, at 10:48 PM, Antoine Pitrou wrote: >I think the DSL itself does warrant public exposure. It will be an >element of the CPython coding style, if its use becomes widespread. We do have PEP 7 after all. No matter what, this stuff has to eventually be well documented outside of the tracker. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Tue, Dec 4, 2012 at 3:54 PM, Brett Cannon wrote: > But going through python-ideas for this I think is a bit much. It would never end. I think an issue on roundup could work just fine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On 12/04/2012 01:49 PM, Chris Angelico wrote: One thing I'm not entirely clear on. Do you run Clinic on a source file and it edits that file, or is it a step in the build process? Your description of a preprocessor makes me think the latter, but the style of code (eg the checksum) suggests the former. You run Clinic on a source file and it edits that file in-place (unless you use -o). It's not currently integrated into the build process. At what time Clinic gets run--manually or automatically--is TBD. Here's my blue-sky probably-overengineered proposal: we (and when I say "we" I mean "I") write a cross-platform C program that could be harmlessly but usefully integrated into the build process. First, we add a checksum for the *input* into the Clinic output. Next, when you run this program, you give it a C file as an argument. First it tries to find a working Python on your path. If it finds one, it uses that Python to run Clinic on the file, propagating any error code outward. If it doesn't find one, it understands enough of the Clinic format to scan the C file looking for Clinic blocks. If it finds one where the checksum doesn't match (for input or output!) it complains loudly and exits with an error code, hopefully bringing the build to a screeching halt. This would integrate Clinic into the build process without making the build reliant on having a Python interpreter available. I get the sneaking suspicion that I'm going to rewrite Clinic to run under either Python 2.7 or 3, //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On 12/04/2012 02:10 PM, Brian Curtin wrote: I think an issue on roundup could work just fine. http://bugs.python.org/issue16612 Cheers, //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Wed, Dec 5, 2012 at 9:17 AM, Larry Hastings wrote: > Here's my blue-sky probably-overengineered proposal: we (and when I say "we" > I mean "I") write a cross-platform C program that could be harmlessly but > usefully integrated into the build process. First, we add a checksum for > the *input* into the Clinic output. Next, when you run this program, you > give it a C file as an argument. First it tries to find a working Python on > your path. If it finds one, it uses that Python to run Clinic on the file, > propagating any error code outward. If it doesn't find one, it understands > enough of the Clinic format to scan the C file looking for Clinic blocks. > If it finds one where the checksum doesn't match (for input or output!) it > complains loudly and exits with an error code, hopefully bringing the build > to a screeching halt. This would integrate Clinic into the build process > without making the build reliant on having a Python interpreter available. That would probably work, but it implies having two places that understand Clinic blocks (the main Python script, and the C binary), with the potential for one of them to have a bug. Is it possible, instead, to divide the build process in half, and actually use the newly-built Python to run all Clinic code? That would put some (maybe a lot of) restrictions on what functionality the Clinic parser is allowed to use, but if it can work, it'd be clean. (The main code of Clinic could still demand a fully-working Python if that's easier; I'm just suggesting making the "check the checksums" part of the same Python script as does the real work.) ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython
On Wed, Dec 5, 2012 at 8:17 AM, Larry Hastings wrote: > I get the sneaking suspicion that I'm going to rewrite Clinic to run under > either Python 2.7 or 3, > For bootstrapping purposes, isn't it enough to just ignore the checksums if there's no Python interpreter already built? We can have a commit hook that rejects a checkin if the checksums don't match so you can't push a change if you've modified the headers without regenerating them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]
On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth wrote: > How to use Obsoletes: > > The author of B decides A is obsolete. > > A releases an empty version of itself that Requires: B > > B Obsoletes: A > > The package manager says "These packages are obsolete: A". Would you like to > remove them? > > User says "OK". > Um, no. Even if the the author of A and B are the same person, you can't remove A if there are other things on the user's system using it. The above scenario does not work *at all*, ever, except in the case where B is simply an updated version of A (i.e. identical API) -- in which case, why bother? To change the project name? (Then it should be "Formerly-named" or something like that, not "Obsoletes".) Please, *please* see the previous Catalog-SIG discussion I linked: this is only one of multiple metadata fields that were thoroughly debunked in that discussion as completely useless for automated dependency management. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]
On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote: > On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth (mailto:dho...@gmail.com)> wrote: > > How to use Obsoletes: > > > > The author of B decides A is obsolete. > > > > A releases an empty version of itself that Requires: B > > > > B Obsoletes: A > > > > The package manager says "These packages are obsolete: A". Would you like to > > remove them? > > > > User says "OK". > > Um, no. Even if the the author of A and B are the same person, you > can't remove A if there are other things on the user's system using > it. The above scenario does not work *at all*, ever, except in the > case where B is simply an updated version of A (i.e. identical API) -- > in which case, why bother? To change the project name? (Then it > should be "Formerly-named" or something like that, not "Obsoletes".) > > You can automatically uninstall A from B in an automatic dependency management system. I *think* RPM does this, at the very least I believe it refuses to install B if A is already there (and the reverse as well).* There's nothing preventing an installer from, during it's attempt to install B, see it Obsoletes A, looking at what depends on A and warning the user what is going to happen and prompt it. I think Obsoletes as is an alright bit of information. I think the biggest flaw with Obsoletes isn't in Obsoletes itself, but is in the lack of a Conflicts tag that has the same functionality (minimally refusal to install both, possibly uninstall the previous one with a prompt to the user). Obsoletes has the semantics of a logical successor (typically renames) while Conflicts should have the semantics of a competitor. distribute would conflict with setuptools, foo2 would Obsoletes foo. * I could be wrong about RPM's treatment of Obsoletes > > Please, *please* see the previous Catalog-SIG discussion I linked: > this is only one of multiple metadata fields that were thoroughly > debunked in that discussion as completely useless for automated > dependency management. > > I don't see this in this thread, could you link it again? > ___ > Python-Dev mailing list > Python-Dev@python.org (mailto:Python-Dev@python.org) > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
