Re: [Python-Dev] Changing Clinic's output

2014-01-11 Thread Larry Hastings
On 01/08/2014 07:08 AM, Barry Warsaw wrote: How hard would it be to put together some sample branches that provide concrete examples of the various options? My own opinion could easily be influenced by having some hands-on time with actual code, and I suspect even Guido could be influenced if h

Re: [Python-Dev] Changing Clinic's output

2014-01-14 Thread Larry Hastings
On 01/11/2014 07:35 PM, Larry Hastings wrote: On 01/08/2014 07:08 AM, Barry Warsaw wrote: How hard would it be to put together some sample branches that provide concrete examples of the various options? My own opinion could easily be influenced by having some hands-on time with actual code

Re: [Python-Dev] Changing Clinic's output

2014-01-14 Thread Larry Hastings
On 01/14/2014 12:48 PM, Zachary Ware wrote: On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings wrote: I have now received exactly zero feedback about the prototype, which suggests people aren't using it. Oops, I had half a post written about this two days ago, but never got it posted.

Re: [Python-Dev] Changing Clinic's output

2014-01-14 Thread Larry Hastings
On 01/14/2014 12:51 PM, Ethan Furman wrote: I checked the README, the current file, and the buffered files. My preferences from highest to lowest: - modified buffer approach - buffer approach - side file Could you put that in the form of numbers from +1 to -1? I'm literally making a

Re: [Python-Dev] Changing Clinic's output

2014-01-14 Thread Larry Hastings
On 01/14/2014 01:38 PM, Raymond Hettinger wrote: On Jan 14, 2014, at 9:12 PM, Antoine Pitrou > wrote: I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach. I concur with Antoine except that I'm

Re: [Python-Dev] Changing Clinic's output

2014-01-14 Thread Larry Hastings
On 01/14/2014 01:38 PM, Raymond Hettinger wrote: FWIW, I think everyone should place a lot of weight on Serhiy's comments and suggestions. His reasoning is clear and compelling. And the thoughts are all soundly based on extensive experience with the clinic's effect on the C source code. One

Re: [Python-Dev] Changing Clinic's output

2014-01-14 Thread Larry Hastings
On 01/14/2014 05:32 PM, Ryan Smith-Roberts wrote: Pondering it this afternoon, I thought of a configuration that minimizes both code churn and readability impact: two buffers. One at the top containing forward declarations and defines (an inline header file if you like), and the rest of the au

Re: [Python-Dev] Changing Clinic's output

2014-01-14 Thread Larry Hastings
On 01/14/2014 12:22 PM, Larry Hastings wrote: On 01/11/2014 07:35 PM, Larry Hastings wrote: I've uploaded a prototype here: https://bitbucket.org/larry/python-clinic-buffer [...] I've created a new repository containing the "concrete examples of the various opti

Re: [Python-Dev] Changing Clinic's output

2014-01-15 Thread Larry Hastings
On 01/15/2014 01:59 AM, Serhiy Storchaka wrote: 15.01.14 00:47, Larry Hastings написав(ла): I also can not change the text, but twice I was a witness as others did. And I see that make this mistake very easily. I also didn't modify the generated text, but twice I was a witness as other

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

2014-01-15 Thread Larry Hastings
On 01/15/2014 08:35 PM, Ryan Smith-Roberts wrote: On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts > wrote: socket.getservbyname(servicename[, protocolname]) -> socket.getservbyname(servicename, protocolname=None) Here is a more complicated example, since t

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

2014-01-15 Thread Larry Hastings
On 01/15/2014 09:37 PM, Guido van Rossum wrote: Well, I think these are mostly artifacts from old times, and usually passing None *should* be the same as omitting the argument. But check each case! Vajrasky Kok's recent posting to python-dev discusses the same problem. His example is iterto

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

2014-01-15 Thread Larry Hastings
On 01/15/2014 10:21 PM, Georg Brandl wrote: Am 16.01.2014 05:35, schrieb Ryan Smith-Roberts: On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts mailto:r...@lab.net>> wrote: socket.getservbyname(servicename[, protocolname]) -> socket.getservbyname(servicename, protocolname=None)

[Python-Dev] Argument Clinic Derby update

2014-01-16 Thread Larry Hastings
The Derby is moving forward, and I have maybe a half-dozen contributors so far. They've made a small dent in making the conversion but I'd have to say it's going slowly. We could use more people contributing patches! To the contributors with patches that are stalled in the tracker: Sorry,

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

2014-01-16 Thread Larry Hastings
On 01/16/2014 03:38 AM, Antoine Pitrou wrote: On Wed, 15 Jan 2014 21:55:46 -0800 Larry Hastings wrote: Passing in "None" here is inconvenient as it's an integer argument. Inconvenient for whom? The callee or the caller? The callee, specifically the C argument parsing co

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

2014-01-16 Thread Larry Hastings
On 01/16/2014 04:21 AM, MRAB wrote: On 2014-01-16 05:32, Larry Hastings wrote: [snip] We could add a special value, let's call it sys.NULL, whose specific semantics are "turns into NULL when passed into builtins". This would solve the problem but it's really, really

Re: [Python-Dev] python code in argument clinic annotations

2014-01-16 Thread Larry Hastings
On 01/16/2014 11:36 AM, Guido van Rossum wrote: On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov wrote: If we keep it strictly declarative, then, at least, we’ll have this possibility in the future. Sounds like a pretty unlikely scenario. Why would you implement clinic in C? We'll never reim

Re: [Python-Dev] python code in argument clinic annotations

2014-01-16 Thread Larry Hastings
On 01/16/2014 11:46 AM, Yury Selivanov wrote: There is just one reason for having it in C -- having it integrated in the build process, so that the generated output/sidefiles are not in the repository. It's possible to integrate Argument Clinic into the build process without rewriting it in C.

[Python-Dev] Closing the Clinic output format debate (at least for now)

2014-01-16 Thread Larry Hastings
The current tally of votes, by order of popularity: Side file: +6 Buffer: +1.5 Multiple buffers, Modified buffer, Forward buffer: +1 Original: -5 However, as stated, support for "side files" will not go in unless Guido explicitly states that it's okay with him. He has not. There

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

2014-01-16 Thread Larry Hastings
On 01/16/2014 12:13 PM, Larry Hastings wrote: The current tally of votes, by order of popularity: Side file: +6 Buffer: +1.5 Multiple buffers, Modified buffer, Forward buffer: +1 Original: -5 I should add, that's out of a total of eleven votes cast. So the side file

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

2014-01-16 Thread Larry Hastings
On 01/16/2014 01:24 PM, Georg Brandl wrote: Although this is neglecting the difference between +0 and -0 :) I hear LibreOffice is accepting external patches again. //arr//y/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/m

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

2014-01-16 Thread Larry Hastings
On 01/16/2014 01:08 PM, Ryan Smith-Roberts wrote: There are two classes of builtins whose signatures do not have these properties. The first is those with very weird signatures, like curses.window.addstr(). It's fine that those don't get converted, they're hopeless. Speaking as the father of

Re: [Python-Dev] PEP 461 Final?

2014-01-17 Thread Larry Hastings
On 01/17/2014 09:46 AM, Neil Schemenauer wrote: Rational "Rationale". "Rational" is an adjective, "Rationale" is a noun. Pedantically yours, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mail

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-18 Thread Larry Hastings
On 01/18/2014 05:28 AM, Nick Coghlan wrote: However, if both Visual Studio and gdb can still find the symbols correctly, even with the ".clinic" extension, then I would consider that a point strongly in favour of Serhiy's suggestion. No, that would be a lack of a point against Serhiy's sug

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-18 Thread Larry Hastings
On 01/18/2014 01:02 AM, Serhiy Storchaka wrote: 1. I very very often use global search in sources. It's my way of navigation and it's my way of investigations. I don't want to get false results in generated files. And it is much easy to specify mask '*.[ch]' or '*.c,*.h' (depending on tool) tha

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-19 Thread Larry Hastings
On 01/18/2014 10:36 PM, Nick Coghlan wrote: On 19 January 2014 10:44, Steve Dower wrote: Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and c

Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()

2014-01-19 Thread Larry Hastings
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 local

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-20 Thread 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/m

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

2014-01-20 Thread Larry Hastings
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().

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-20 Thread Larry Hastings
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

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-20 Thread Larry Hastings
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&#

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-20 Thread Larry Hastings
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

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

2014-01-20 Thread Larry Hastings
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

Re: [Python-Dev] Argument Clinic: Bug? self converters are not preserved when cloning functions

2014-01-20 Thread Larry Hastings
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

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

2014-01-20 Thread Larry Hastings
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

Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()

2014-01-20 Thread Larry Hastings
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

Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()

2014-01-21 Thread Larry Hastings
On 01/21/2014 12:59 AM, Serhiy Storchaka wrote: 21.01.14 04:44, Nikolaus Rath написав(ла): 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

Re: [Python-Dev] Using argument clinic to replace timemodule.c:parse_time_t_args()

2014-01-21 Thread Larry Hastings
Yes, I meant in the definition of the convertor class.  You can fix c_default in converter_init. On Jan 21, 2014 7:19 PM, Nikolaus Rath wrote: > > Larry Hastings writes: > > A comment on your approach so far: I'm very much against giving > > "default" a

Re: [Python-Dev] .clinic.c vs .c.clinic

2014-01-22 Thread Larry Hastings
On 01/22/2014 08:20 AM, Serhiy Storchaka wrote: 20.01.14 13:14, Serhiy Storch aka написав(ла): Contestant 5: "Put in __clinic__ directory, add .h" foo.c -> __clinic__/foo.c.h foo.h -> __clinic__/foo.h.h -0.5. As far as 4 and 5 have equal total votes, I change my vote for 5 from

[Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

2014-01-24 Thread Larry Hastings
BACKGROUND (skippable if you're a know-it-all) Argument parsing for Python functions follows some very strict rules. Unless the function implements its own parsing like so: def black_box(*args, **kwargs): there are some semantics that are always true. For example: * Any parameter th

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

2014-01-24 Thread Larry Hastings
On 01/24/2014 07:07 AM, Larry Hastings wrote: b) Functions where there's no static Python value that behaves identically to not passing in that parameter (aka "the dynamic default problem") Ouch! Sorry, I forgot a detail here. This can also be another form of NULL proble

[Python-Dev] Quick poll: should help() show bound arguments?

2014-01-24 Thread Larry Hastings
(Quick, because apparently nobody reads the long ones!) In Python 3.3: >>> class C: ...def foo(self, a): pass ... >>> c = C() >>> help(c.foo) shows you the signature "foo(self, a)". As in, it claims it accepts two parameters. The function actually only accepts one par

[Python-Dev] New policies for the Derby -- please read!

2014-01-25 Thread Larry Hastings
1) New policy for what can and cannot be converted during the Derby First, let me apologize for only figuring this out now. The Derby has been a learning process, discovering things that Argument Clinic didn't handle. And there were a lot of funny edge cases that we weren't going to discov

Re: [Python-Dev] Quick poll: should help() show bound arguments?

2014-01-25 Thread Larry Hastings
On 01/25/2014 03:34 AM, Anders J. Munch wrote: Larry Hastings wrote: inspect.signature gets this right: >>> import inspect >>> str(inspect.signature(c.foo)) '(a)' Not always. : Python 3.4.0b2+ (default:32f9e0ae23f7, Jan 18 2014, 13:56:31) : [GCC 4.2

Re: [Python-Dev] Quick poll: should help() show bound arguments?

2014-01-25 Thread Larry Hastings
On 01/25/2014 05:37 AM, Antoine Pitrou wrote: Speaking of which, I think asking for votes before all arguments have been made is counter-productive. Sorry, I didn't realize there was an established protocol for this. //arry/ ___ Python-Dev mailing l

Re: [Python-Dev] New policies for the Derby -- please read!

2014-01-25 Thread Larry Hastings
On 01/25/2014 07:26 AM, Nick Coghlan wrote: However, you've indicated that adding varargs support is going to take you quite a bit of work, so postponing it is an option definitely worth considering at this point in the release cycle. It's worth considering. I'm estimating it's about 1.5 days'

[Python-Dev] The Argument Clinic Derby is drawing to a close

2014-01-26 Thread Larry Hastings
The first release candidate of Python 3.4 will be tagged in about two weeks. We need to be completely done with the Derby by then. And it's going to take a while to review and iterate on the patches we've got. Therefore: I'm going to stop accepting submissions for new patches in two days.

Re: [Python-Dev] The Argument Clinic Derby is drawing to a close

2014-01-26 Thread Larry Hastings
On 01/26/2014 04:24 PM, Larry Hastings wrote: Patches posted to the issue tracker on or after Wednesday Jan 29 at 12:00:01am will not be accepted. Sorry, forgot to specify the time zone: PST, which is GMT -08:00. Put another way, the submission window closes about 55.5 hours from when I

Re: [Python-Dev] The Argument Clinic Derby is drawing to a close

2014-01-26 Thread Larry Hastings
On 01/26/2014 04:24 PM, Larry Hastings wrote: The first release candidate of Python 3.4 will be tagged in about two weeks. We need to be completely done with the Derby by then. And it's going to take a while to review and iterate on the patches we've got. Since I was asked to c

Re: [Python-Dev] The Argument Clinic Derby is drawing to a close

2014-01-26 Thread Larry Hastings
On 01/26/2014 08:07 PM, Tshepang Lekhonkhobe wrote: On Mon, Jan 27, 2014 at 2:24 AM, Larry Hastings wrote: The first release candidate of Python 3.4 will be tagged in about two weeks. We need to be completely done with the Derby by then. And it's going to take a while to review and it

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-26 Thread Larry Hastings
On 01/26/2014 08:40 PM, Alexander Belopolsky wrote: On Sun, Jan 26, 2014 at 11:26 PM, Vajrasky Kok mailto:sky@speaklikeaking.com>> wrote: In case we are taking "not backporting anything at all" road, what is the best fix for the document? I would say no fix is needed for this do

[Python-Dev] [RELEASED] Python 3.4.0b3

2014-01-26 Thread Larry Hastings
he final release is projected for mid-March 2014. To download Python 3.4.0b3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b3 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Rel

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-27 Thread Larry Hastings
On 01/27/2014 01:39 AM, Antoine Pitrou wrote: On Sun, 26 Jan 2014 21:01:08 -0800 Larry Hastings wrote: On 01/26/2014 08:40 PM, Alexander Belopolsky wrote: On Sun, Jan 26, 2014 at 11:26 PM, Vajrasky Kok mailto:sky@speaklikeaking.com>> wrote: In case we are taking "not

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-27 Thread Larry Hastings
On 01/27/2014 01:47 AM, Mark Lawrence wrote: On 27/01/2014 01:52, Nick Coghlan wrote: In 3.5, that will be passing None, rather than -1. For those proposing to change the maintenance releases, how should a user relying on this misbehaviour update their code to handle it? I'm -1 on using None

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-27 Thread Larry Hastings
On 01/27/2014 04:56 AM, Steven D'Aprano wrote (rearranged slightly so I could make my points in order): I'm confused... you seem to be saying that you are *against* changing the behaviour of repeat so that: repeat(x, -1) and repeat(x, times=-1) behave the same. Is that actually wh

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-27 Thread Larry Hastings
On 01/27/2014 06:00 PM, Vajrasky Kok wrote: On Mon, Jan 27, 2014 at 9:13 PM, Larry Hastings wrote: I apologize for not making myself clear. But that's part of what I meant, yes: we should preserve the existing behavior of times=-1 when passed in by position or by keyword. However, we s

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-27 Thread Larry Hastings
On 01/27/2014 06:26 PM, Vajrasky Kok wrote: So I believe the doc fix is required then. I propose the docstring should describe only supported behavior, and the docs in the manual should mention the unsupported behavior. However, I'm interested in Raymond's take, as he's the original author o

Re: [Python-Dev] Add PyType_GetSlot

2014-01-28 Thread Larry Hastings
On 01/28/2014 12:27 AM, "Martin v. Löwis" wrote: I'd like to resolve a long-standing issue of the stable ABI in 3.4: http://bugs.python.org/issue17162 The issue is that, since PyTypeObject is opaque, module authors cannot get at tp_free, which they may need to in order to implement tp_dealloc p

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-28 Thread Larry Hastings
On 01/28/2014 06:18 AM, Ethan Furman wrote: On 01/28/2014 04:37 AM, Steven D'Aprano wrote: On Mon, Jan 27, 2014 at 10:06:57PM -0800, Larry Hastings wrote: .. note: if "times" is specified using a keyword argument, and provided with a negative value, repeat yields the

Re: [Python-Dev] weird docstring generated by argument clinic

2014-01-29 Thread Larry Hastings
On 01/29/2014 10:25 PM, Stefan Behnel wrote: Hi, for two days now, the signature embedding tests in Cython have been failing with this (doctest) error: """ Expected: f_D(long double D) -> long double Got: f_DNone f_D(long double D) -> long double """ The string "f_DNone" should

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

2014-01-31 Thread Larry Hastings
On 01/28/2014 09:18 PM, Ethan Furman wrote: On 01/28/2014 06:50 PM, Larry Hastings wrote: I think the "times behaves differently when passed by name versus passed by position" behavior falls exactly into this category, and its advice on how to handle it is sound. I don't

[Python-Dev] The docstring hack for signature information has to go

2014-02-03 Thread Larry Hastings
A quick summary of the context: currently in CPython 3.4, a builtin function can publish its "signature" as a specially encoded line at the top of its docstring. CPython internally detects this line inside PyCFunctionObject.__doc__ and skips past it, and there's a new getter at PyCFunctionO

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-03 Thread Larry Hastings
On 02/03/2014 07:08 AM, Barry Warsaw wrote: On Feb 03, 2014, at 06:43 AM, Larry Hastings wrote: But that only fixes part of the problem. Our theoretical extension that wants to be binary-compatible with 3.3 and 3.4 still has a problem: how can they support signatures? They can't

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-03 Thread Larry Hastings
On 02/03/2014 09:46 AM, Guido van Rossum wrote: Can you summarize why neither of the two schemes you tried so far worked? Certainly. In the first attempt, the signature looked like this: (arguments)\n The "(arguments)" part of the string was 100% compatible with Python syntax. So much

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-04 Thread Larry Hastings
On 02/03/2014 08:19 PM, Guido van Rossum wrote: But why do you even need a flag? Reading issue 20075 where the complaint started, it really feels that the change was an overreaction to a very minimal problem. I'll cop to that. I'm pretty anxious about trying to "get it right". My worry wa

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-04 Thread Larry Hastings
On 02/03/2014 12:55 PM, Terry Reedy wrote: I think the solution adopted should be future-oriented (ie, clean in the future) even if the cost is slight awkwardness in 3.3. Just a minor point: I keep saying 3.3, but I kind of mean "3.2 through 3.3". I believe the binary ABI shipped with 3.2.

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-04 Thread Larry Hastings
On 02/03/2014 01:10 PM, Zachary Ware wrote: What about just choosing a marker value that is somewhat less unsightly? "signature = (", or "parameters: (", or something (better) to that effect? It may not be beautiful in 3.3, but we can at least make it make sense. It's a reasonable enough idea

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-04 Thread Larry Hastings
On 02/03/2014 02:06 PM, Gregory P. Smith wrote: Wouldn't your proposal to extend the PyMethodDef structure would require ifdef's and make it impossible to include the type information in something compiled against the 3.3 headers that you want to use in 3.4 without recompiling? It might use #

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-04 Thread Larry Hastings
On 02/03/2014 02:26 PM, Antoine Pitrou wrote: How do you create an array that mixes PyMethodDefs and PyMethodDefExs together? You're right, you wouldn't be able to. For my PyMethodDefEx proposal, the entire array would have to be one way or the other. It sounds like METH_SIGNATURE is th

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-04 Thread Larry Hastings
On 02/04/2014 01:41 AM, Georg Brandl wrote: Clever, but due to the "hidden" space it also increases the frustration factor for people trying to find out "why is this accepted as a signature and not this". I don't think a well-chosen visible separator is worse off, such as "--\n". I could live

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-04 Thread Larry Hastings
On 02/03/2014 08:05 AM, Stefan Krah wrote: I think we may slowly get into PEP territory here. Just imagine that we settle on X, then decide at a later point to have a standard way of adding type annotations, then find that X does not work because of (unknown). I'm mentioning this because signat

Re: [Python-Dev] __doc__ regression

2014-02-04 Thread Larry Hastings
On 02/04/2014 04:17 AM, Antoine Pitrou wrote: As you see the signature string has vanished from the __doc__ contents. This means that any tool directly processing __doc__ attributes to generate (e.g.) automatic API docs will produce less useful docs. Why couldn't these tools use inspect.Signatu

Re: [Python-Dev] __doc__ regression

2014-02-04 Thread Larry Hastings
On 02/04/2014 05:19 AM, Victor Stinner wrote: 2014-02-04 Larry Hastings : Why couldn't these tools use inspect.Signature? inspect.Signature was added in Python 3.3. Python 2 is still widely used, and some Linux distro only provide Python 3.2. By the way, help(dict.fromkeys) looks t

Re: [Python-Dev] __doc__ regression

2014-02-04 Thread Larry Hastings
On 02/04/2014 05:24 AM, Antoine Pitrou wrote: On Tue, 04 Feb 2014 05:08:28 -0800 Larry Hastings wrote: On 02/04/2014 04:17 AM, Antoine Pitrou wrote: As you see the signature string has vanished from the __doc__ contents. This means that any tool directly processing __doc__ attributes to

[Python-Dev] Decision on the docstring hack (was Re: The docstring hack for signature information has to go)

2014-02-04 Thread Larry Hastings
In the absence of a ruling from above I'm making a decision. I say we keep the docstring hack, but go back to the human-readable version, only this time with a *much* stricter signature. That should reduce the number of false positives to zero. Furthermore, I say we don't add any flags--ad

Re: [Python-Dev] The docstring hack for signature information has to go

2014-02-05 Thread Larry Hastings
On 02/05/2014 05:52 AM, "Martin v. Löwis" wrote: D: Add a new type slot for method signatures. This would be a tp_signature field, along with a new slot id Py_tp_signature. The signature field itself could be struct PyMethodSignature { char *method_name; char *method_signature; }; Tha

[Python-Dev] [RELEASED] Python 3.4.0 release candidate 1

2014-02-10 Thread Larry Hastings
he final release is projected for mid-March 2014. To download Python 3.4.0rc1 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0rc1 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings,

[Python-Dev] Python 3.4: What to do about the Derby patches

2014-02-16 Thread Larry Hastings
Let's begin with a status update of The Great Argument Clinic Conversion Derby. In retrospect, the Derby was way too ambitious. Once it started I was quickly overwhelmed. Even doing nothing but Derby work, all day every day for two straight weeks, I couldn't keep up with all the bug fixes

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

2014-02-16 Thread Larry Hastings
On 02/16/2014 12:36 PM, Serhiy Storchaka wrote: 16.02.14 20:31, Larry Hastings написав(ла): 4) We accelerate the schedule for 3.4.1 slightly, so we can get these new signatures into the hands of users sooner. Specifically, I propose we ship 3.4.1 two months after 3.4.0. I figure we would

[Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-16 Thread Larry Hastings
Right now we're in the "release candidate" phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho h

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-17 Thread Larry Hastings
On 02/16/2014 03:45 PM, Paul Moore wrote: is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just m

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

2014-02-17 Thread Larry Hastings
/dev/peps/pep-0436/ I need to clean it up and submit it for final inspection. This is on my to-do list for before 3.4.0 final. 2014-02-16 19:31 GMT+01:00 Larry Hastings : 1) We merge the Derby patch for the builtins module into 3.4, simply because it will "demo well". Where is th

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-17 Thread Larry Hastings
On 02/17/2014 03:20 PM, Victor Stinner wrote: 2014-02-17 0:25 GMT+01:00 Larry Hastings : You might think that anything you check in to the "default" branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-18 Thread Larry Hastings
On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-18 Thread Larry Hastings
On 02/18/2014 03:56 PM, Matthias Klose wrote: Am 19.02.2014 00:46, schrieb Larry Hastings: On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-18 Thread Larry Hastings
On 02/18/2014 03:54 PM, Victor Stinner wrote: 2014-02-19 0:46 GMT+01:00 Larry Hastings : Is there *any* reason to make this branch public before 3.4.0 final? I'm a little bit worried by the fact that buildbots will not test it. "fact"? http://docs.python.org/devguide

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-18 Thread Larry Hastings
On 02/18/2014 04:19 PM, Matthias Klose wrote: Am 19.02.2014 01:05, schrieb Larry Hastings: On 02/18/2014 03:56 PM, Matthias Klose wrote: Am 19.02.2014 00:46, schrieb Larry Hastings: On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local

[Python-Dev] Preview of 3.4 rc2 (so far) is up

2014-02-18 Thread Larry Hastings
The URL has changed slightly. Please go here: http://midwinter.com/~larry/3.4.status/ You'll notice two things: * a "merge.status.html" file, which shows you the list of revisions that I've cherry-picked after rc1. * a tarball containing the resulting source tree. As I cherry-pick m

Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up

2014-02-19 Thread Larry Hastings
On 02/19/2014 02:04 AM, Nick Coghlan wrote: On 19 Feb 2014 14:05, "Larry Hastings" <mailto:la...@hastings.org>> wrote: > > > > The URL has changed slightly. Please go here: >> >> http://midwinter.com/~larry/3.4.status/ <http://midwinter.co

Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up

2014-02-19 Thread Larry Hastings
On 02/19/2014 07:20 AM, Yury Selivanov wrote: About 21 of those are related to asyncio. On 2/19/2014, 7:42 AM, Antoine Pitrou wrote: On Tue, 18 Feb 2014 20:03:31 -0800 Larry Hastings wrote: Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, That'

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

2014-02-19 Thread Larry Hastings
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: > A "user beware, this may be rebased without warning" clone would be > fine for that purpose, and I suspect in most cases just running rc2 > -> final with such a clone available (preserving Larry's current > workflow

[Python-Dev] Second preview of 3.4.0rc2 is up

2014-02-20 Thread Larry Hastings
This time I was a lot more careful about Misc/NEWS items. The graft process likes to link in improper changes. So every time I have a graft merge collision, I now recheck what the revision I'm merging has done, and I only keep Misc/NEWS entries that are relevant. I just realized that I ba

[Python-Dev] Third preview of 3.4.0rc2 is up

2014-02-21 Thread Larry Hastings
We're now up to 66 cherry-picks. 75%+ of those are asyncio changes. Hopefully I won't have to redo the cherry-picking from scratch again, I can just pile more picks on top of the ones I've got. As before you'll find the results here: http://midwinter.com/~larry/3.4.status/ //arry/ ___

Re: [Python-Dev] Third preview of 3.4.0rc2 is up

2014-02-21 Thread Larry Hastings
On 02/21/2014 01:30 AM, Ned Deily wrote: In article <53070a8a.8080...@hastings.org>, Larry Hastings wrote: As before you'll find the results here: http://midwinter.com/~larry/3.4.status/ Status says that: eef7899ea7ab Doc: do not rely on checked-out Sphinx too

[Python-Dev] One more cherry-pick request for 3.4.0 that I'd like a little public debate on

2014-02-21 Thread Larry Hastings
Victor has asked me to cherry-pick 180e4b678003: http://bugs.python.org/issue20320 (original issue) http://hg.python.org/cpython/rev/180e4b678003/ (checkin into trunk) http://bugs.python.org/issue20646 (cherry-pick request) This revision changes the rounding behavior of fractional-s

[Python-Dev] Fourth (final?) preview of rc2 is up

2014-02-22 Thread Larry Hastings
Only three new revisions this time. Victor must have taken the day off! //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/arc

Re: [Python-Dev] One more cherry-pick request for 3.4.0 that I'd like a little public debate on

2014-02-23 Thread Larry Hastings
On 02/22/2014 03:27 AM, Antoine Pitrou wrote: On Sat, 22 Feb 2014 01:42:57 -0600 Larry Hastings wrote: Victor has asked me to cherry-pick 180e4b678003: http://bugs.python.org/issue20320 (original issue) http://hg.python.org/cpython/rev/180e4b678003/ (checkin into trunk) http

[Python-Dev] [RELEASED] Python 3.4.0 release candidate 2 is now available

2014-02-23 Thread Larry Hastings
rg/download/releases/3.4.0/ Once I can update the new web site, Python 3.4.0rc2 will be available here: http://python.org/download/releases/ (I'm not sure what the final URL will be, but you'll see it listed on that page.) Please consider trying Python 3.4.0rc2 with your code an

Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread Larry Hastings
On 02/26/2014 11:13 PM, Georg Brandl wrote: Am 26.02.2014 17:09, schrieb Ryan Gonzalez: I like Py_DECREF_REPLACE. It gives the impression that it decrefs the original and replaces it. Agreed, most other suggestions are not really explicit enough. +1 from me too. When I saw Py_SETREF I though

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

2014-03-03 Thread Larry Hastings
On 03/03/2014 03:01 AM, Victor Stinner wrote: Hi, I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. //arry/ ___ Python-Dev mailing

Re: [Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

2014-03-03 Thread Larry Hastings
On 03/03/2014 05:05 AM, Victor Stinner wrote: 2014-03-03 13:13 GMT+01:00 Larry Hastings : I would like to know if the cherry-picking rule still applies for Python 3.4 final? Can I open an issue if I want to see a changeset in the final version? Sadly, yes. Ok, I created: http

<    1   2   3   4   5   6   7   8   9   >