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
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?
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
+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:
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
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
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
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
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
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
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
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
]
/
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 -
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
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
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
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
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 -
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
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
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
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.
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 -
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
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__.
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
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
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?
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 -
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
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
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
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 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 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
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
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
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
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
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
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,
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
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
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
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
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]
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
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 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.
49 matches
Mail list logo