Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/19/2014 08:29 AM, Ethan Furman wrote: On 01/19/2014 03:32 AM, Georg Brandl wrote: Am 19.01.2014 11:19, schrieb Larry Hastings: Not kidding, my best idea so far is foo.clinic.h.h, Why not always put clinic into its own directory? Modules/mathmodule.c - Modules/clinic/mathmodule.c.h Modules/mathmodule.h - Modules/clinic/mathmodule.h.h At least that is consistent, allows easy exclusion in tools, and gets rid of the additional clinic in the filename. +1 If AC will work with both .c and .h files. I think a separate directory is the way to go. In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions. Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-) The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames foo.c and foo.h. I would strongly prefer that all transformations be expressable using str.format(transformation, filename=foo.c, basename=foo, extension=.c) . The contestants so far: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h I didn't add a contestant for what Stefan Krah originally suggested (foo.c - foo.h) because it's not clear how this would handle foo.h. You'll notice the current behavior is no longer in the running, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
Am 20.01.2014 09:05, schrieb Larry Hastings: On 01/19/2014 08:29 AM, Ethan Furman wrote: On 01/19/2014 03:32 AM, Georg Brandl wrote: Am 19.01.2014 11:19, schrieb Larry Hastings: Not kidding, my best idea so far is foo.clinic.h.h, Why not always put clinic into its own directory? Modules/mathmodule.c - Modules/clinic/mathmodule.c.h Modules/mathmodule.h - Modules/clinic/mathmodule.h.h At least that is consistent, allows easy exclusion in tools, and gets rid of the additional clinic in the filename. +1 If AC will work with both .c and .h files. I think a separate directory is the way to go. In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions. Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-) The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames foo.c and foo.h. I would strongly prefer that all transformations be expressable using str.format(transformation, filename=foo.c, basename=foo, extension=.c) . The contestants so far: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h -0. (Clutters the directory.) Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h -1. (Autoconf...) Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic -1. (Doesn't get included in global *.[ch] search, clutters the directory.) Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h +1. Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h -1. (Too complicated; this isn't Python packages we're talking about.) Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 461 Final?
On 01/19/2014 11:10 PM, Stephen J. Turnbull wrote: Ethan Furman writes: This argument is specious. I don't think so. I think it's a good argument for the future of Python code. I agree that restricting bytes '%'-formatting to ASCII is a good idea, but you should base your arguments on a correct description of what's going on. It's not an issue of representability. It's an issue of we should support this for ASCII because it's a useful, nearly universal convention, and we should not support ASCII supersets because that leads to mojibake. Then you could have your text /and/ your numbers be in your own language. My language uses numerals other than those in the ASCII repertoire in a rather stylized way. I can't use __format__ for that, because it depends on context, anyway. Most of the time the digits in the ASCII set are used (especially in tables and the like). I believe that's true for all languages nowadays. Lots of features can be abused. That doesn't mean we shouldn't talk about the intended use cases and encourage those. I only objected to claims that issues of representability and what I can do with __format__ support the preferred use cases, not to descriptions of the preferred use cases. Thank you. I appreciate your time. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
+1 for Contestant 4 for me as well, +0 for Contestant 5, -1 for the others. Same reasons as Georg, even where my votes are different. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 01/19/2014 08:30 PM, Nick Coghlan wrote: Guido, Larry and I thrashed out the required semantics for parameter groups at PyCon US last year (and I believe the argument clinic PEP describes those accurately). They're mainly needed to represent oddball signatures like range() and slice(). However, I'm inclined to say that the affected functions should simply not support introspection until Python 3.5. It's not just a matter of the data model, there's also the matter of defining the string representation. Au contraire!, says the man writing patches. How it works right now: Argument Clinic publishes the signature information for builtins as the first line of the builtin's docstring. It gets clipped off before __doc__ returns it, and it's made available as __text_signature__. inspect.Signature retrieves this string and passes it in to ast.parse(). It then walks the resulting tree, producing the Function and Parameter objects as it goes. Argument Clinic has the information about positional-only parameters and optional groups, but it can't express it in this text signature. The text signature is parsed by ast.parse(), and ast.parse() only understands Python syntax. So the information is thrown away. Boo hoo. I was trying to change this with PEP 457: http://www.python.org/dev/peps/pep-0457/ PEP 457 proposed new Python syntax for positional-only parameters and optional groups. The syntax looks like Argument Clinic's syntax for these features, but with commas replacing newlines: Positional-only parameters are delimited with a single slash. In def foo(self, /, a), self is positional-only and a is not. Optional groups are parameters wrapped with square brackets, with the brackets never appearing between a parameter and a comma. In def foo(a, [b, c]), b and c are in an optional group together. Groups can be nested with some restrictions. To be clear: I wasn't proposing we actually add this syntax to Python! Just that, *if* we added support for positional-only parameters and optional groups, it would be this syntax. I did propose that documentation and tools like Argument Clinic could use it now. PEP 457 didn't get any support. People said: We don't need to define syntax if we're not going to use it. If you really need this you can do it privately. Okay! I'll do it privately! Hopefully this week! Step 1: Extend the format of the __text_signature__ to use PEP 457 syntax. Then *strip* that extra syntax in inspect.Signature, producing a sanitized string that is parseable by ast.parse(), and storing the extra information on the side. Pass the sanitized string in to ast.parse(), walk the parse tree, and merge the positional-only / optional group information into the Parameter objects as I go. inspect.Signature objects can already represent positional-only parameters, and I plan to add a new member (group, see below) that lets them represent optional groups too. Hooray! inspect.Signature objects can now represent almost every Python callable! Step 2: make pydoc print the optional groups information, aka the PEP 457 square brackets, because that's uncontroversial. pydoc on builtins has printed things like range([start], stop, [step]) for decades. Everybody intuitively understands it, everybody likes it. Step 3, if people want it: Also make pydoc display which parameters are positional-only. I was going to propose that in a couple of days, when I was getting near ready to implement it. But I guess we're discussing it now. Unsurprisingly, I propose to use the PEP 457 syntax here. Regarding Step 3 above, here's something to consider. str(inspect.signature(foo)) produces a very nice-looking string, which currently is (almost!) always parseable by ast.parse() like so: sig = inspect.signature(foo) if sig: ast.parse(def foo + str(sig) + : pass) On the one hand, this mechanical round-trip ability is kind of a nice property. On the other hand, it does restrict the format of the string--it can't have our square brackets, it can't have our /,. Meanwhile __str__ makes no guarantee that the string it returns is a valid Python expression. We could do both. Make inspect.Signature.__str__ only return Python compatible syntax, and allow another mechanism for pydoc to produce something more informative (but not Python compatible) for the user, like so: str(inspect.signature(_pickle.Pickler.dump)) '(self, obj)' pydoc.plain(pydoc.render_doc(pickle.Pickler.dump)) ...\n_pickle.Pickler.dump(self, /, obj)\n... Or we could do it the other way around. So I guess I'm proposing four alternatives: 1) inspect.Signature.__str__() must always be parsable by ast.parse(). 2) inspect.Signature.__str__() must always be parsable by ast.parse(). Add another method to inspect.Signature that can use PEP 457 syntax, use that from pydoc. 3) inspect.Signature.__str__()
Re: [Python-Dev] .clinic.c vs .c.clinic
On 1/20/2014 4:07 AM, Nick Coghlan wrote: +1 for Contestant 4 for me as well, +0 for Contestant 5, -1 for the others. Same reasons as Georg, even where my votes are different. Ditto for me. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
20.01.14 10:05, Larry Hastings написав(ла): The contestants so far: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h -0.5. Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h -1. Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic +1. (Doesn't get included in global *.[ch] search, generated files are located close to origins.) Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h -0.5. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, 20 Jan 2014 00:05:16 -0800 Larry Hastings la...@hastings.org wrote: On 01/19/2014 08:29 AM, Ethan Furman wrote: On 01/19/2014 03:32 AM, Georg Brandl wrote: Am 19.01.2014 11:19, schrieb Larry Hastings: Not kidding, my best idea so far is foo.clinic.h.h, Why not always put clinic into its own directory? Modules/mathmodule.c - Modules/clinic/mathmodule.c.h Modules/mathmodule.h - Modules/clinic/mathmodule.h.h At least that is consistent, allows easy exclusion in tools, and gets rid of the additional clinic in the filename. +1 If AC will work with both .c and .h files. I think a separate directory is the way to go. In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions. Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-) The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames foo.c and foo.h. I would strongly prefer that all transformations be expressable using str.format(transformation, filename=foo.c, basename=foo, extension=.c) . The contestants so far: Contestant 1: Add .clinic.h +1 Contestant 2: Add .ac.h -0.5 Contestant 3: Add .clinic -1 Contestant 4: Put in clinic directory, add .h +1 Contestant 5: Put in __clinic__ directory, add .h -0.5 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 20 January 2014 20:16, Larry Hastings la...@hastings.org wrote: On 01/19/2014 08:30 PM, Nick Coghlan wrote: Guido, Larry and I thrashed out the required semantics for parameter groups at PyCon US last year (and I believe the argument clinic PEP describes those accurately). They're mainly needed to represent oddball signatures like range() and slice(). However, I'm inclined to say that the affected functions should simply not support introspection until Python 3.5. It's not just a matter of the data model, there's also the matter of defining the string representation. Au contraire!, says the man writing patches. When I wrote that, I was thinking we had made inspect.Signature.__repr__ produce a nice string format, but then I noticed in the REPL today that we never got around to doing that - I think because we didn't know how to handle positional-only arguments, which already can't be expressed as Python syntax. (I haven't checked if we have an RFE filed anywhere) However, while I know you're keen to finally make introspection work for all C level callables in 3.4, even the ones with signatures that can't be expressed as Python function signatures, I'd like to strongly encourage you to hold off on that last part until Python 3.5. We're already in beta, we're already introducing a lot of code churn to get the C level callables that *can* have their signatures expressed as Python syntax converted, so where's the harm to users in saying that C level callables with non-Python signatures still don't support introspection in Python 3.4? Almost no C level callables support programmatic introspection in Python 3.3, so even what inspect.signature will already provide in beta 3 is a big step forward. While the text string used to communicate between Argument Clinic and inspect.signature will be private, the representation on inspect.Signature objects will be a new *public* API. As the discussions between you, me and Yury show, I don't think there's an immediately obvious best answer of how to do that. Your suggestion of just adding the group numbers to the Parameter objects would *work*, but it's not very Pythonic - we have container types that support nesting, which seems like a more natural structure for indicating parameter groups at the Python level. Essentially, the group number proposal feels like the kind of low level interface returned by getfullargspec(), not the kind of high level interface defined for inspect.Signature in PEP 362. It's going to take a while to come up with a public API for this aspect of C level signatures that feels right to at least you, me and Yury, and the beta period *really* isn't the right time to be doing that. If other changes like the binary interpolation proposals and adding the PEP 451 based target attributes to runpy can wait until Python 3.5 due to feature freeze, then I think adding full C level signature support to inspect.Signature can also wait. That way, you can resurrect PEP 457, recast it as proposing an *output* format for inspect.Signature.__repr__(), add an inspect.Signature.fromstr() API that can use it to create a signature object from __text_signature__ attributes (rather than relying on ast.parse), add the optional group support and do it *right*, rather than trying to squeeze it in as a new public API during the beta period, which may lock us in to supporting an introspection API we later regret. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 20 January 2014 21:14, Serhiy Storchaka storch...@gmail.com wrote: 20.01.14 10:05, Larry Hastings написав(ла): Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using Objects/clinic, Python/clinic, Modules/clinic as appropriate. That's substantially *less* directory clutter rather than more, just like __pycache__ vs the old model of implicitly creating adjacent .pyc and .pyo files. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
20.01.14 15:03, Nick Coghlan написав(ла): On 20 January 2014 21:14, Serhiy Storchaka storch...@gmail.com wrote: 20.01.14 10:05, Larry Hastings написав(ла): Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using Objects/clinic, Python/clinic, Modules/clinic as appropriate. This means the appearance of directories with the common name clinic in random places of the source tree. Some special name (__clinic__, .clinic) looks slightly less confusing to me. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
20.01.14 06:19, Nikolaus Rath написав(ла): This works if the user calls time.gmtime(None), but it fails for time.gmtime(). It seems that in that case my C converter function is never called. What's the trick that I'm missing? /*[clinic input] time.gmtime [ seconds: time_t ] / [clinic start generated code]*/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings la...@hastings.org wrote: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h -0 Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h -1 Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic -1 (This will break too many tools in the C/C++ tools ecosystem and I am not convinced by any of the arguments given those far.) Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h +1 Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h -1 (clinic without the dunders more clear for a directory name.) -- Meador ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
Larry, Nick, On January 20, 2014 at 8:00:35 AM, Nick Coghlan (ncogh...@gmail.com) wrote: Your proposal gets a no, absolutely not vote from me. 1. We already have a notion of optional parameters. Parameters with default values are optional. 2. Your proposed syntax doesn't mention how we'd actually establish default values for parameters. So it's insufficient to handle existing code. 3. Your syntax/semantics, as described, can't convey the concept of optional groups. So it's insufficient to solve the problem it sets out to solve. 4. Your proposed syntax changes 80% of existing code--any parameter with a default value. I don't know how you concluded this was simpler. I withdraw my proposal in its current form. Turns out I’ve missed groups definition in PEP 436. But, just want to add a few things. My proposal is still good for the other problem — having support for optional parameters (where “optional” is in a sense of itertools.repeat last parameter). Again, my example from the first email in this thread. Suppose you want to write itertools.repeat in python (where “n” can not be None, what matters is *was is passed or not*): _marker = object() def repeat(elem, n=_marker): pass Now, if you do 'str(inspect.signature(repeat))’ you’ll have something like: '(elem, n=object object at 0x108650080)’ However, if we choose to have a special marker object defined in the stdlib, you’d write: def repeat(elem, n=functools.optional): if n is functools.optional: # no param was passed and str of signature would look like ‘(elem[, n])’. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
Larry Hastings la...@hastings.org wrote: Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h +1 for this, 0 for the rest. Bonus points for any other directory name that is more self-descriptive. ;) Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 3:05 AM, Larry Hastings la...@hastings.org wrote: On 01/19/2014 08:29 AM, Ethan Furman wrote: On 01/19/2014 03:32 AM, Georg Brandl wrote: Am 19.01.2014 11:19, schrieb Larry Hastings: Not kidding, my best idea so far is foo.clinic.h.h, Why not always put clinic into its own directory? Modules/mathmodule.c - Modules/clinic/mathmodule.c.h Modules/mathmodule.h - Modules/clinic/mathmodule.h.h At least that is consistent, allows easy exclusion in tools, and gets rid of the additional clinic in the filename. +1 If AC will work with both .c and .h files. I think a separate directory is the way to go. In theory, Argument Clinic works with any file for which it can iterate over by lines and recognize comments. It current supports C and Python files and automatically recognizes a bunch of extensions. Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-) The rules: * The poll will be over in 48 hours, maybe sooner if a winner emerges early. * Please express your vote from -1 to +1. -0 and +0 will only be differentiated during a tiebreaker. * If you don't vote for a contestant, your vote will be assumed to be 0. * You may change your vote at any time while the poll is still running. * If you wish to nominate a new contestant, you may. Please give the contestant a name, and express how it would transform the filenames foo.c and foo.h. I would strongly prefer that all transformations be expressable using str.format(transformation, filename=foo.c, basename=foo, extension=.c) . The contestants so far: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h +0 Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h -1 Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic +0 Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h +0 Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h +1 I didn't add a contestant for what Stefan Krah originally suggested (foo.c - foo.h) because it's not clear how this would handle foo.h. You'll notice the current behavior is no longer in the running, And +1 to making a side file the default for ease of use. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
The contestants so far: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h +0 Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h +1 Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic +0 Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1 Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h -1 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings la...@hastings.org wrote: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h -0 Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h -1 Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic -0 Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h +1 Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h +0 -- Zach ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah ste...@bytereef.org wrote: Bonus points for any other directory name that is more self-descriptive. ;) Argument Clinic is a PyArg_Parse* preprocessor, AFAIU. Why not call the directory pyargprep, pyargparsers or such? Or may be aclinic-output? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 10:44 AM, Oleg Broytman p...@phdru.name wrote: On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah ste...@bytereef.org wrote: Bonus points for any other directory name that is more self-descriptive. ;) Argument Clinic is a PyArg_Parse* preprocessor, AFAIU. Why not call the directory pyargprep, pyargparsers or such? Or may be aclinic-output? The fact that it emits PyArg_Parse*-using code is an implementation detail. It could easily change if we want since Argument Clinic abstracts out argument parsing entirely. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 10:05 AM, Larry Hastings la...@hastings.org wrote: Okay, I'm taking a poll. I will total your answers and take the result... strongly under advisement. ;-) +1 for #5, +0.5 for #4, -1 for the rest. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
Stefan Krah ste...@bytereef.org wrote: Larry Hastings la...@hastings.org wrote: Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h +1 for this, 0 for the rest. Bonus points for any other directory name that is more self-descriptive. ;) On second thought, I do find that having Modules/cjkcodecs Modules/clinic looks kind of weird. So I'm +1 for __clinic__, 0 on the rest. +2 for something more self-explanatory like: Modules/__arghandlers__ Modules/__autogen__ Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
Am 20.01.2014 14:31, schrieb Serhiy Storchaka: 20.01.14 15:03, Nick Coghlan написав(ла): On 20 January 2014 21:14, Serhiy Storchaka storch...@gmail.com wrote: 20.01.14 10:05, Larry Hastings написав(ла): Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using Objects/clinic, Python/clinic, Modules/clinic as appropriate. This means the appearance of directories with the common name clinic in random places of the source tree. Some special name (__clinic__, .clinic) looks slightly less confusing to me. clinic shouldn't be such a common name in C soures :) Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/20/2014 12:05 AM, Larry Hastings wrote: Contestant 1: Add .clinic.h foo.c - foo.c.clinic.h foo.h - foo.h.clinic.h -1 Contestant 2: Add .ac.h foo.c - foo.c.ac.h foo.h - foo.h.ac.h -1 Contestant 3: Add .clinic foo.c - foo.c.clinic foo.h - foo.h.clinic +0 Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h +0.5 Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h +1 -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h This is cached output right? IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it. +1 -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw ba...@python.org wrote: On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h This is cached output right? Yes, it's generated entirely based on data provided in original source file. IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it. More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
The trick you're missing is that *any time* you have an optional argument
with a custom converter[1], PyArg_ParseTuple *only* calls the converter
function in the case that the user *actually supplies some value*. This is
a basic property of an optional argument. Another property is that the
c_default is evaluated *every time*, as it is set *before* the call to
PyArg_ParseTuple. Are these the best ways to do things? Maybe not, but it's
how they are.
Please do not use a custom converter for this case. It can't work. Please
do what I outlined earlier (untested, somewhat verbose code follows):
static int
parse_time_t_arg(PyObject *arg, time_t *when)
{
if (arg == NULL || arg == Py_None) {
*when = time(NULL);
return 1;
}
if (_PyTime_ObjectToTime_t(arg, when) == -1)
return 0;
return 1;
}
/*[clinic input]
time.gmtime
seconds: object = None
[clinic start generated code]*/
{
time_t when;
if (0 == parse_time_t_arg(seconds, when))
return NULL;
...
[1] If you set a default value, or put it in brackets as Serhiy later
recommends, it works the same.
On Sun, Jan 19, 2014 at 8:19 PM, Nikolaus Rath nikol...@rath.org wrote:
Larry Hastings la...@hastings.org writes:
On 01/18/2014 09:52 PM, Ryan Smith-Roberts wrote:
I still advise you not to use this solution. time() is a system call
on many operating systems, and so it can be a heavier operation than
you'd think. Best to avoid it unless it's needed (on FreeBSD it
seems to add about 15% overhead to localtime(), for instance).
I agree. Converting to Argument Clinic should not cause a performance
regression. Please don't add new calls to time() for the sake of
making code more generic.
A better choice would be to write a converter function in C, then use
a custom converter that called it. Nikolaus: Is that something you're
comfortable doing?
I think I'll need some help. I don't know how to handle the case where
the user is not passing anything.
Here's my attempt:
,
| /* C Converter for argument clinic
|If obj is NULL or Py_None, return current time. Otherwise,
|convert Python object to time_t.
| */
| static int
| PyObject_to_time_t(PyObject *obj, time_t *stamp)
| {
| if (obj == NULL || obj == Py_None) {
| *stamp = time(NULL);
| }
| else {
| if (_PyTime_ObjectToTime_t(obj, stamp) == -1)
| return 0;
| }
| return 1;
| }
|
| /*[python input]
| class time_t_converter(CConverter):
| type = 'time_t'
| converter = 'PyObject_to_time_t'
| default = None
| [python start generated code]*/
| /*[python end generated code:
checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/
|
|
| /*[clinic input]
| time.gmtime
|
| seconds: time_t
| /
|
| [clinic start generated code]*/
`
but this results in the following code:
,
| static PyObject *
| time_gmtime(PyModuleDef *module, PyObject *args)
| {
| PyObject *return_value = NULL;
| time_t seconds;
|
| if (!PyArg_ParseTuple(args,
| |O:gmtime,
| PyObject_to_time_t, seconds))
| goto exit;
| return_value = time_gmtime_impl(module, seconds);
|
| exit:
| return return_value;
| }
`
This works if the user calls time.gmtime(None), but it fails for
time.gmtime(). It seems that in that case my C converter function is
never called.
What's the trick that I'm missing?
Thanks!
-Nikolaus
--
Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6
02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/rmsr%40lab.net
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/20/2014 11:46 AM, Brett Cannon wrote: On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote: On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h This is cached output right? Yes, it's generated entirely based on data provided in original source file. IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it. More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method. Won't AC put those macros in the source file for you? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
Am 20.01.2014 21:05, schrieb Ethan Furman: On 01/20/2014 11:46 AM, Brett Cannon wrote: On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote: On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h This is cached output right? Yes, it's generated entirely based on data provided in original source file. IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it. More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method. Won't AC put those macros in the source file for you? No, currently it wouldn't know where to look. And that's a good thing because AC never should modify anything not inbetween clinic start generated code and clinic end generated code. But Larry has said that in the future the wohl PyMethodDef array might be generated by AC in a separate block (that you have to indicate in the file as well). Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 1/20/2014 7:59 AM, Nick Coghlan wrote: However, while I know you're keen to finally make introspection work for all C level callables in 3.4, even the ones with signatures that can't be expressed as Python function signatures, I'd like to strongly encourage you to hold off on that last part until Python 3.5. ... That way, you can resurrect PEP 457, recast it as proposing an *output* format for inspect.Signature.__repr__(), add an inspect.Signature.fromstr() API that can use it to create a signature object from __text_signature__ attributes (rather than relying on ast.parse), add the optional group support and do it *right*, rather than trying to squeeze it in as a new public API during the beta period, which may lock us in to supporting an introspection API we later regret. I agree. What we can do with the API we have already is a great advance. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 1/20/2014 6:01 AM, Terry Reedy wrote: On 1/20/2014 4:07 AM, Nick Coghlan wrote: +1 for Contestant 4 for me as well, +0 for Contestant 5, -1 for the others. Same reasons as Georg, even where my votes are different. Ditto for me. Except that after reading other responses, I might switch 4 and 5, so make that +1 for either 4 or 5. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/20/2014 05:03 AM, Nick Coghlan wrote: On 20 January 2014 21:14, Serhiy Storchaka storch...@gmail.com wrote: 20.01.14 10:05, Larry Hastings написав(ла): Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using Objects/clinic, Python/clinic, Modules/clinic as appropriate. You're correct, I'm not talking about a top-level directory here. I'm talking about creating a clinic subdirectory in the same directory as the original file. The transformation suggested above was exact. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/20/2014 11:09 AM, Barry Warsaw wrote: On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h This is cached output right? IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it. +1 It's cached output. The difference to __pycache__ is that the output will be checked in, and is something you might ever want to examine. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/20/2014 12:14 PM, Georg Brandl wrote: Am 20.01.2014 21:05, schrieb Ethan Furman: On 01/20/2014 11:46 AM, Brett Cannon wrote: On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote: On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote: Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h This is cached output right? Yes, it's generated entirely based on data provided in original source file. IOW, it can be regenerated if it's missing. If so, this seems like a nice parallel to __pycache__. It's mostly hidden until you want to go looking for it. More-or-less. The key difference is you will most likely look at the generated file *once* to copy-and-paste the relevant macros to paste into your source file for use (e.g. the relevant MethodDef stuff). But it's a one-time thing that never has to be done again as long as you don't rename a function or method. Won't AC put those macros in the source file for you? No, currently it wouldn't know where to look. And that's a good thing because AC never should modify anything not inbetween clinic start generated code and clinic end generated code. So, if I understand correctly, by moving into a sidefile approach, we will have go to a two-pass system? Once to ACify the file and run Argument Clinic on it, and then again to add in the macros? Is this basically the same as it was with the buffer approach? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/20/2014 01:47 PM, Ethan Furman wrote: So, if I understand correctly, by moving into a sidefile approach, we will have go to a two-pass system? Once to ACify the file and run Argument Clinic on it, and then again to add in the macros? Is this basically the same as it was with the buffer approach? Let me paraphrase this to add context, to see if I understand your question correctly. When you add the Argument Clinic blob to a function, Argument Clinic generates some C code. That code contains a parsing function, an impl function (which you implement), and a macro to paste into the correct slot in the PyMethodDef structure. The name of the macro is full_name_of_function.upper() + _METHODDEF. However, it can be inconvenient to guess what the actual macro name is, so most people fill out the structure, run clinic.py on the C file, then go hunting for the METHODDEF macro definition to get the name. This is what you refer to as a two-pass system: edit the file, run Argument Clinic on it, then edit it to put the METHODDEF macro in the right spot. If that's what you meant, then: yes, and yes. It's possible to skip the second pass if you're comfortable guessing the generated name of the macro, but that's just one more thing for people to remember, and hunting for it is easier. And yes, whether it's original output or buffer or clinic file (I'm trying to deprecate the name side file, it was a dumb idea), the destination Argument Clinic writes to doesn't dramatically alter what it writes. //arry/ p.s. Your saying macros threw me off, as there's only one macro. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
20.01.14 20:09, Georg Brandl написав(ла): Am 20.01.2014 14:31, schrieb Serhiy Storchaka: 20.01.14 15:03, Nick Coghlan написав(ла): On 20 January 2014 21:14, Serhiy Storchaka storch...@gmail.com wrote: 20.01.14 10:05, Larry Hastings написав(ла): Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using Objects/clinic, Python/clinic, Modules/clinic as appropriate. This means the appearance of directories with the common name clinic in random places of the source tree. Some special name (__clinic__, .clinic) looks slightly less confusing to me. clinic shouldn't be such a common name in C soures :) Sources tree already has one clinic directory (Tools/clinic/). ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
Am 20.01.2014 22:47, schrieb Ethan Furman: Won't AC put those macros in the source file for you? No, currently it wouldn't know where to look. And that's a good thing because AC never should modify anything not inbetween clinic start generated code and clinic end generated code. So, if I understand correctly, by moving into a sidefile approach, we will have go to a two-pass system? Once to ACify the file and run Argument Clinic on it, and then again to add in the macros? No. It is completely the same as in the current all-in-one-file approach. Is this basically the same as it was with the buffer approach? It's the same as it always was. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 21 Jan 2014 06:26, Terry Reedy tjre...@udel.edu wrote: On 1/20/2014 7:59 AM, Nick Coghlan wrote: However, while I know you're keen to finally make introspection work for all C level callables in 3.4, even the ones with signatures that can't be expressed as Python function signatures, I'd like to strongly encourage you to hold off on that last part until Python 3.5. ... That way, you can resurrect PEP 457, recast it as proposing an *output* format for inspect.Signature.__repr__(), add an inspect.Signature.fromstr() API that can use it to create a signature object from __text_signature__ attributes (rather than relying on ast.parse), add the optional group support and do it *right*, rather than trying to squeeze it in as a new public API during the beta period, which may lock us in to supporting an introspection API we later regret. I agree. What we can do with the API we have already is a great advance. It also occurred to me last night that PEP 457 could define a functools.textsignature decorator to permit describing a particular signature on arbitrary callables (using the attribute already added for Argument Clinic, but extended to arbitrary types). That would allow signature overrides without needing to import the inspect module at startup. Cheers, Nick. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
On 21 Jan 2014 08:20, Serhiy Storchaka storch...@gmail.com wrote: 20.01.14 20:09, Georg Brandl написав(ла): Am 20.01.2014 14:31, schrieb Serhiy Storchaka: 20.01.14 15:03, Nick Coghlan написав(ла): On 20 January 2014 21:14, Serhiy Storchaka storch...@gmail.com wrote: 20.01.14 10:05, Larry Hastings написав(ла): Contestant 4: Put in clinic directory, add .h foo.c - clinic/foo.c.h foo.h - clinic/foo.h.h -1. (Generated files are located far from origins, directory name clutters the namespace of directory names). Larry's not talking about a top level directory here (at least I hope he isn't). This proposal would mean using Objects/clinic, Python/clinic, Modules/clinic as appropriate. This means the appearance of directories with the common name clinic in random places of the source tree. Some special name (__clinic__, .clinic) looks slightly less confusing to me. clinic shouldn't be such a common name in C soures :) Sources tree already has one clinic directory (Tools/clinic/). This observation and the cjkcodecs comparison has prompted me to switch my votes for #4 and #5: +1 for __clinic__, +0 for clinic. I still prefer a subdirectory to adjacent files, though. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 01/20/2014 04:59 AM, Nick Coghlan wrote: When I wrote that, I was thinking we had made inspect.Signature.__repr__ produce a nice string format, but then I noticed in the REPL today that we never got around to doing that - I think because we didn't know how to handle positional-only arguments, which already can't be expressed as Python syntax. (I haven't checked if we have an RFE filed anywhere) I don't know what you had intended to do, but right now inspect.Signature inherits the standard repl from object. inspect.Signature.__str__ produces something that looks like a Python function signature, starting and ending with parentheses. (For those of you unfamiliar with inspect.Signature: A signature is agnostic about the name of the function. So it doesn't include the name.) However, while I know you're keen to finally make introspection work for all C level callables in 3.4, even the ones with signatures that can't be expressed as Python function signatures, I'd like to strongly encourage you to hold off on that last part until Python 3.5. If we hold off on all of this until 3.5, the signatures for most builtins will be wrong in 3.4, because most builtins take positional-only parameters. I had higher hopes for Python 3.4 than that. To be honest I'd rather not have the feature at all than have it be wrong most of the time. I think it's fair to summarize your argument as there could be monsters lurking in CPython with signatures that can't be expressed in PEP 457 syntax. To me this smacks of FUD. Let me open my kimono and tell you all the counter-examples we know of so far. * socket.sendto() has an optional group in the middle of required parameters. (This signature is from 1993.) PEP 457 could support this just by relaxing one requirement. I know what's needed here, but given that PEP 457 was such a dud I haven't bothered to update it. Regardless, Argument Clinic, and the syntax used for text signatures, could (and I expect will soon) support this. The inspect.Parameter.group proposal from my email last night supports this just fine. * itertools.repeat() has a parameter that behaves differently if it's passed by keyword vs passed by position. Guido already ruled that this signature must be changed so it is representable with Python syntax--this behavior is a bug. * Many functions have default values that are not representable in Python, chiefly a NULL pointer. Guido has already ruled that these signatures should be changed so that they're representable in Python. The best approach is often accepting None, which is inconvenient for non-pointer arguments like integers. Right now Argument Clinic gives you no assistance in this area, but I plan to add explicit support making it easy (via nullable ints). In short, there's a clear trend: functions must have signatures representable in Python syntax, with the exception of optional groups which are a legacy feature we can't get rid of but won't support in Python syntax. Any functions whose signatures are not representable in Python syntax shall be tweaked until they are. Any new monsters we discover lurking in CPython will be slain, not supported. - We could split the difference, and not add a feature to the inspect module to support optional groups. We could still support marking positional-only parameters, as inspect currently supports that. That would mean nearly all signatures for builtins would be correct. Personally I'd rather go the extra distance and support optional groups too. There are important callables that can only be expressed with optional groups (range, type). Given the trend above, Parameter arguments with optional groups should be sufficient to express every signature available in Python. We've come this far... or, as the British say, in for a penny, in for a pound. Let's hash it out right now and get it done. While the text string used to communicate between Argument Clinic and inspect.signature will be private, the representation on inspect.Signature objects will be a new *public* API. As the discussions between you, me and Yury show, I don't think there's an immediately obvious best answer of how to do that. Your suggestion of just adding the group numbers to the Parameter objects would *work*, but it's not very Pythonic - we have container types that support nesting, Apparently you didn't read my proposal in the email you replied to. I didn't propose that group contain a number, I proposed it contain a ParameterGroup object that supports nesting. We could take another approach, one you seem to be suggesting, where the nesting is outside the Parameter objects. In this alternate approach, the Signature.parameters array can contain either Parameter objects or OrderedDicts. The nested OrderedDicts themselves can contain either Parameter objects or more nested OrderedDicts. The API would specify that the
Re: [Python-Dev] .clinic.c vs .c.clinic
On 01/20/2014 01:57 PM, Larry Hastings wrote: If that's what you meant, then: yes, and yes. It's possible to skip the second pass if you're comfortable guessing the generated name of the macro, but that's just one more thing for people to remember, and hunting for it is easier. And yes, whether it's original output or buffer or clinic file (I'm trying to deprecate the name side file, it was a dumb idea), the destination Argument Clinic writes to doesn't dramatically alter what it writes. Okay, thanks. And I'm happy to call them clinic files. :) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 21 Jan 2014 09:26, Larry Hastings la...@hastings.org wrote: On 01/20/2014 04:59 AM, Nick Coghlan wrote: When I wrote that, I was thinking we had made inspect.Signature.__repr__ produce a nice string format, but then I noticed in the REPL today that we never got around to doing that - I think because we didn't know how to handle positional-only arguments, which already can't be expressed as Python syntax. (I haven't checked if we have an RFE filed anywhere) I don't know what you had intended to do, but right now inspect.Signature inherits the standard repl from object. inspect.Signature.__str__ produces something that looks like a Python function signature, starting and ending with parentheses. (For those of you unfamiliar with inspect.Signature: A signature is agnostic about the name of the function. So it doesn't include the name.) However, while I know you're keen to finally make introspection work for all C level callables in 3.4, even the ones with signatures that can't be expressed as Python function signatures, I'd like to strongly encourage you to hold off on that last part until Python 3.5. If we hold off on all of this until 3.5, the signatures for most builtins will be wrong in 3.4, because most builtins take positional-only parameters. I had higher hopes for Python 3.4 than that. To be honest I'd rather not have the feature at all than have it be wrong most of the time. Positional only is fine - PEP 362 already handles those. It only doesn't handle things like range(), and those callables should continue to not support introspection at all rather than reporting an incorrect signature. I think it's fair to summarize your argument as there could be monsters lurking in CPython with signatures that can't be expressed in PEP 457 syntax. No. I am saying there *are* signatures that the *inspect module* cannot express in its public API. You already *know* that, since you are proposing to add a new feature (group support) to inspect.Signature late in the beta cycle in order to handle those cases. I am saying that's a gross violation of our established processes. The argument clinic conversions can be defended as internal implementation details. A new public feature in the inspect module cannot. Please turn the question around and look at it with your release manager hat on rather than your creator of Argument Clinic hat: if I came to you and said I wanted to add a new public API to the inspect module after the second beta release, what would you say? Can you honestly say that if *someone else* was proposing the inclusion of a new public API this late in the release cycle, you would say yes? If I can wait until 3.5 to add PEP 451 target parameters to runpy because I was too busy to land that before feature freeze, and Eric can wait to fully support PEP 451 for builtin and extension modules, and Ethan can wait to restore binary interpolation, and Antoine can wait a full release cycle between adding qualified names in 3.3 and actually seeing them used in an updated pickle protocol in 3.4, there's no good reason to rush adding introspection support for oddball legacy signatures to the inspect module. Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Argument Clinic: Bug? self converters are not preserved when cloning functions
Hi, I'm working on converting Objects/bytearray.c and Objects/bytes.c. For bytes, the strip methods need a self converter so that they get a PyBytesObject* instead of PyObject*. However, having set this in bytes.strip and cloning that clinic definition for bytes.lstrip and bytes.rstrip, it appears that the self converter wasn't set on lstrip and rstrip. Removing the cloning and copying the argument definitions resolved the issue. Is this a bug? - Tal ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Argument Clinic: Bug? self converters are not preserved when cloning functions
Please file an issue on the tracker and add me to the nosy list. Do that next time, too; this didn't need to go to python-dev. On Jan 20, 2014 5:46 PM, Tal Einat talei...@gmail.com wrote: Hi, I'm working on converting Objects/bytearray.c and Objects/bytes.c. For bytes, the strip methods need a self converter so that they get a PyBytesObject* instead of PyObject*. However, having set this in bytes.strip and cloning that clinic definition for bytes.lstrip and bytes.rstrip, it appears that the self converter wasn't set on lstrip and rstrip. Removing the cloning and copying the argument definitions resolved the issue. Is this a bug? - Tal ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/larry%40hastings.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
Ryan Smith-Roberts r...@lab.net writes:
The trick you're missing is that *any time* you have an optional argument
with a custom converter[1], PyArg_ParseTuple *only* calls the converter
function in the case that the user *actually supplies some value*. This is
a basic property of an optional argument. Another property is that the
c_default is evaluated *every time*, as it is set *before* the call to
PyArg_ParseTuple. Are these the best ways to do things? Maybe not, but it's
how they are.
Please do not use a custom converter for this case. It can't work.
Well, I thought I was following Larry's recommendation:
A better choice would be to write a converter function in C, then use
a custom converter that called it. Nikolaus: Is that something you're
comfortable doing?
..and I assumed he'd know best. Did I misunderstand that quote?
Please do what I outlined earlier (untested, somewhat verbose code
follows):
static int
parse_time_t_arg(PyObject *arg, time_t *when)
{
if (arg == NULL || arg == Py_None) {
*when = time(NULL);
return 1;
}
if (_PyTime_ObjectToTime_t(arg, when) == -1)
return 0;
return 1;
}
Ahm, this is exactly the code that I wrote (and you even quoted it
below), only with the identifiers renamed.
/*[clinic input]
time.gmtime
seconds: object = None
[clinic start generated code]*/
{
time_t when;
if (0 == parse_time_t_arg(seconds, when))
return NULL;
That's fine with me too. I'd just like Larry to sign off on it, because
as far as I know, he'll be the one to review my patch.
Best,
-Nikolaus
[1] If you set a default value, or put it in brackets as Serhiy later
recommends, it works the same.
On Sun, Jan 19, 2014 at 8:19 PM, Nikolaus Rath nikol...@rath.org wrote:
Larry Hastings la...@hastings.org writes:
On 01/18/2014 09:52 PM, Ryan Smith-Roberts wrote:
I still advise you not to use this solution. time() is a system call
on many operating systems, and so it can be a heavier operation than
you'd think. Best to avoid it unless it's needed (on FreeBSD it
seems to add about 15% overhead to localtime(), for instance).
I agree. Converting to Argument Clinic should not cause a performance
regression. Please don't add new calls to time() for the sake of
making code more generic.
A better choice would be to write a converter function in C, then use
a custom converter that called it. Nikolaus: Is that something you're
comfortable doing?
I think I'll need some help. I don't know how to handle the case where
the user is not passing anything.
Here's my attempt:
,
| /* C Converter for argument clinic
|If obj is NULL or Py_None, return current time. Otherwise,
|convert Python object to time_t.
| */
| static int
| PyObject_to_time_t(PyObject *obj, time_t *stamp)
| {
| if (obj == NULL || obj == Py_None) {
| *stamp = time(NULL);
| }
| else {
| if (_PyTime_ObjectToTime_t(obj, stamp) == -1)
| return 0;
| }
| return 1;
| }
|
| /*[python input]
| class time_t_converter(CConverter):
| type = 'time_t'
| converter = 'PyObject_to_time_t'
| default = None
| [python start generated code]*/
| /*[python end generated code:
checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/
|
|
| /*[clinic input]
| time.gmtime
|
| seconds: time_t
| /
|
| [clinic start generated code]*/
`
but this results in the following code:
,
| static PyObject *
| time_gmtime(PyModuleDef *module, PyObject *args)
| {
| PyObject *return_value = NULL;
| time_t seconds;
|
| if (!PyArg_ParseTuple(args,
| |O:gmtime,
| PyObject_to_time_t, seconds))
| goto exit;
| return_value = time_gmtime_impl(module, seconds);
|
| exit:
| return return_value;
| }
`
This works if the user calls time.gmtime(None), but it fails for
time.gmtime(). It seems that in that case my C converter function is
never called.
What's the trick that I'm missing?
Thanks!
-Nikolaus
--
Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6
02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/rmsr%40lab.net
--
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
Serhiy Storchaka storch...@gmail.com writes:
20.01.14 06:19, Nikolaus Rath написав(ла):
This works if the user calls time.gmtime(None), but it fails for
time.gmtime(). It seems that in that case my C converter function is
never called.
What's the trick that I'm missing?
/*[clinic input]
time.gmtime
[
seconds: time_t
]
/
Ahh, interesting. So this works, but now the C default is evaluated even
if the user passed an argument (so that answers my question about
decreased performance in the other subthread). The generated code is:
time_gmtime(PyModuleDef *module, PyObject *args)
{
PyObject *return_value = NULL;
int group_right_1 = 0;
time_t seconds = time(NULL);
switch (PyTuple_GET_SIZE(args)) {
case 0:
break;
case 1:
if (!PyArg_ParseTuple(args, O:gmtime, PyObject_to_time_t,
seconds))
return NULL;
group_right_1 = 1;
break;
default:
PyErr_SetString(PyExc_TypeError, time.gmtime requires 0 to 1
arguments);
return NULL;
}
return_value = time_gmtime_impl(module, group_right_1, seconds);
All in all, I'm still not sure how I'm supposed to proceed. I see the
following options (and I'm fine with all of them):
1. Use the option group with a custom converter. This means a time(NULL)
call even if the caller passed a parameter.
2. Declare the _impl parameter as PyObject* instead of time_t, and
explicitly call a C conversion function.
3. Patch clinic.py to only evaluate the C default if the caller does not
pass a parameter. This seemest cleanest, but I don't know if the
design of clinic.py actually allows that.
Best,
Nikolaus
--
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature.object, argument clinic and grouped parameters
On 01/20/2014 03:53 PM, Nick Coghlan wrote: Please turn the question around and look at it with your release manager hat on rather than your creator of Argument Clinic hat: if I came to you and said I wanted to add a new public API to the inspect module after the second beta release, what would you say? Can you honestly say that if *someone else* was proposing the inclusion of a new public API this late in the release cycle, you would say yes? You're right. Optional group information won't be a public API in 3.4. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .clinic.c vs .c.clinic
Am 20.01.2014 09:15, schrieb Georg Brandl: Contestant 5: Put in __clinic__ directory, add .h foo.c - __clinic__/foo.c.h foo.h - __clinic__/foo.h.h -1. (Too complicated; this isn't Python packages we're talking about.) Make that +0. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()
On 01/20/2014 06:44 PM, Nikolaus Rath wrote:
All in all, I'm still not sure how I'm supposed to proceed. I see the
following options (and I'm fine with all of them):
1. Use the option group with a custom converter. This means a time(NULL)
call even if the caller passed a parameter.
2. Declare the _impl parameter as PyObject* instead of time_t, and
explicitly call a C conversion function.
3. Patch clinic.py to only evaluate the C default if the caller does not
pass a parameter. This seemest cleanest, but I don't know if the
design of clinic.py actually allows that.
clinic.py is not flexible enough to allow initialization code after the
call to the converter.
A comment on your approach so far: I'm very much against giving
default a default value in the constructor. I realize that hack saves
you having to say = NULL in a lot of places. But explicit is better
than implicit, and we're going to read these signatures a lot more often
than we write them, and I want Clinic signatures to be easy to read at
first glance.
Anyway, you're right, the converter function is not called if a value is
not passed in to convert it. I think this is more complicated than you
suspect, because PyArg_ParseWhatnot doesn't tell you whether or not it
processed a parameter. You have to detect it yourself, generally
through a clever choice of a default value in C. But there are no
illegal values of time_t.
All is not lost! What follows is rough pseudo-C code, hopefully you can
take it from here.
typedef struct {
int set;
time_t when;
} clinic_time_t;
#define DEFAULT_CLINIC_TIME_T {0, 0}
static int
parse_clinic_time_t_arg(PyObject *arg, clinic_time_t *ct)
{
if (arg == NULL)
return 1;
if (arg == Py_None)
return 0;
if (_PyTime_ObjectToTime_t(arg, ct-when) == -1) {
set = 1;
return 0;
}
return 1;
}
static int post_parse_clinic_time_t(clinic_time_t *ct) {
if (ct-set)
return 0;
ct-when = time(NULL);
return 0;
}
/*[python input]
class clinic_time_t_converter(CConverter):
type = 'clinic_time_t'
converter = 'parse_clinic_time_t'
c_default = 'DEFAULT_CLINIC_TIME_T'
[python start generated code]*/
/*[python end generated code: checksum=...]*/
Now you can use clinic_time_t. Parameters declared clinic_time_t can be
required, or they can be optional; if they're optional give them a
default value of None. You'll have to call post_parse_clinic_time_t()
by hand in your impl function; I'll see if I can extend Clinic so
converters can emit code after a successful call to the parse function
but before the call to the impl. Also, the converter probably isn't
quite right, you'll have to play with impl_by_reference and
parse_by_reference and add and remove asterisks and ampersands to make
sure the code is 100% correct. Examine the implementation of path_t in
Modules/posixmodule.c, as that does about the same thing.
And of course clinic_time_t is a poor name, perhaps you can come up with
a better one.
That should work,
//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
