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. Decla
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
__
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 wou
Serhiy Storchaka 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.gm
Ryan Smith-Roberts 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.
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 wrote:
>
> Hi,
>
> I'm working on converting Objects/bytearray.c and Objects/bytes.c.
>
> For bytes, the strip methods need a "self
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 ap
On 21 Jan 2014 09:26, "Larry Hastings" 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
>> th
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, whet
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
On 21 Jan 2014 08:20, "Serhiy Storchaka" 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 wrote:
>
> 20.01.14 10:05, Larry Hasting
On 21 Jan 2014 06:26, "Terry Reedy" 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 t
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
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 wrote:
20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> cli
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
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"
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,
On 01/20/2014 05:03 AM, Nick Coghlan wrote:
On 20 January 2014 21:14, Serhiy Storchaka 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 origi
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 a
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 u
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.
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?
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_defau
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 enti
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 __pycac
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.
Am 20.01.2014 14:31, schrieb Serhiy Storchaka:
> 20.01.14 15:03, Nick Coghlan написав(ла):
>> On 20 January 2014 21:14, Serhiy Storchaka wrote:
>>> 20.01.14 10:05, Larry Hastings написав(ла):
Contestant 4: "Put in clinic directory, add .h"
foo.c -> clinic/foo.c.h
foo.
Stefan Krah wrote:
> Larry Hastings 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 though
On Mon, Jan 20, 2014 at 10:05 AM, Larry Hastings 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@pytho
On Mon, Jan 20, 2014 at 10:44 AM, Oleg Broytman wrote:
> On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah
> 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 "
On Mon, Jan 20, 2014 at 04:07:51PM +0100, Stefan Krah
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"?
O
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings 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.
>
> 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
>
> Contes
On Mon, Jan 20, 2014 at 3:05 AM, Larry Hastings 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 it
Larry Hastings 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
___
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 mentio
On Mon, Jan 20, 2014 at 2:05 AM, Larry Hastings 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 -
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
]
/
20.01.14 15:03, Nick Coghlan написав(ла):
On 20 January 2014 21:14, Serhiy Storchaka 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 origin
On 20 January 2014 21:14, Serhiy Storchaka 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
On 20 January 2014 20:16, Larry Hastings 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
On Mon, 20 Jan 2014 00:05:16 -0800
Larry Hastings 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 clin
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.
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@p
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().
+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
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 arg
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 dir
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
49 matches
Mail list logo
