Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-04 Thread Chris Angelico
On Fri, Aug 5, 2016 at 4:37 AM, Terry Reedy wrote: > Making repeat a keyword would have such an extremely high cost > that it is out of the question and not a sane proposal. > To start with, it is used in two major, widely used APIs. > > itertools.repeat + 50 uses in other

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-04 Thread Terry Reedy
Making repeat a keyword would have such an extremely high cost that it is out of the question and not a sane proposal. To start with, it is used in two major, widely used APIs. itertools.repeat + 50 uses in other itertools and tests + all the imports and and uses of repeat() in code all over

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-04 Thread Steven D'Aprano
On Thursday 04 August 2016 19:13, BartC wrote: > On 04/08/2016 04:23, Steven D'Aprano wrote: >> On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > >>> So the idea that remembering 'repeat N' is a cognitive burden, and the >>> myriad string operations for example are not, is ridiculous. >> >> Who says

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-04 Thread Chris Angelico
On Thu, Aug 4, 2016 at 7:13 PM, BartC wrote: > On 04/08/2016 04:23, Steven D'Aprano wrote: >> >> On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > > >>> So the idea that remembering 'repeat N' is a cognitive burden, and the >>> myriad string operations for example are not, is

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-04 Thread BartC
On 04/08/2016 04:23, Steven D'Aprano wrote: On Wed, 3 Aug 2016 08:16 pm, BartC wrote: So the idea that remembering 'repeat N' is a cognitive burden, and the myriad string operations for example are not, is ridiculous. Who says it isn't a cognitive burden? Of course it is. The difference is

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-03 Thread Steven D'Aprano
On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > On 03/08/2016 06:43, Steven D'Aprano wrote: > >> Not everything that is done is worth the cognitive burden of memorising a >> special case. > > >> In some ways, Python is a more minimalist language than you like. That's >> okay, you're allowed to

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-03 Thread Chris Angelico
On Wed, Aug 3, 2016 at 8:16 PM, BartC wrote: > On 03/08/2016 06:43, Steven D'Aprano wrote: > >> Not everything that is done is worth the cognitive burden of memorising a >> special case. > > > >> In some ways, Python is a more minimalist language than you like. That's >>

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-03 Thread BartC
On 03/08/2016 06:43, Steven D'Aprano wrote: Not everything that is done is worth the cognitive burden of memorising a special case. In some ways, Python is a more minimalist language than you like. That's okay, you're allowed to disagree with some design decisions. Well it's

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Steven D'Aprano
On Wednesday 03 August 2016 05:14, BartC wrote: > It's fundamental in that, when giving instructions or commands in > English, it frequently comes up when you want something done a set > number of times: > > "Give me 20 push-ups" At which point the person will invariable drop to the ground and

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread BartC
On 02/08/2016 22:27, Terry Reedy wrote: On 8/2/2016 7:05 AM, BartC wrote: Your objection to a feature such as 'repeat N' doesn't really stack up. My objection is that there is a real cost that MUST be stacked up against the benefit. ... Anyway, if that was a valid objection, it would

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Paul Rubin
Terry Reedy writes: > I think it is you who is unwilling to admit that nearly everything > that would be useful also has a cost, and that the ultimate cost of > adding every useful feature, especially syntax features, would be to > make python less unusable. I think you meant

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Terry Reedy
On 8/2/2016 7:05 AM, BartC wrote: On 31/07/2016 19:58, Terry Reedy wrote: On 7/31/2016 6:18 AM, BartC wrote: repeat N: The benefit is not so much performance, but being able to express something very easily and quickly. The cost of the 'repeat' contraction is that one cannot use the

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Chris Angelico
On Wed, Aug 3, 2016 at 5:55 AM, Christian Gollwitzer wrote: >> - Arbitrary-precision non-integers > > > https://pypi.python.org/pypi/bigfloat/ > > ? Wasn't aware of that. Cool. Not that I need it very often (and when I do, I can use Pike, which has MPFR support built-in). Or I

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Christian Gollwitzer
Am 02.08.16 um 16:58 schrieb Chris Angelico: - A more free-form declarative syntax for laying out GUI code Actually, the Tkinter wrapper misses one feature of grid in Tcl/Tk: You can write something like grid .a .b grid .c .d to lay out a GUI 2x2 grid using "ASCII-art". There is a package

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Chris Angelico
On Wed, Aug 3, 2016 at 3:57 AM, Steven D'Aprano wrote: > On Wed, 3 Aug 2016 03:12 am, BartC wrote: > >> That's not a fundamental language feature. Repeat-N is. And if properly >> designed, isn't an extra feature at all but a special case of a generic >> loop. > > Which

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread BartC
On 02/08/2016 18:57, Steven D'Aprano wrote: On Wed, 3 Aug 2016 03:12 am, BartC wrote: That's not a fundamental language feature. Repeat-N is. And if properly designed, isn't an extra feature at all but a special case of a generic loop. Which means it is NOT a fundamental language feature.

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Steven D'Aprano
On Wed, 3 Aug 2016 03:12 am, BartC wrote: > That's not a fundamental language feature. Repeat-N is. And if properly > designed, isn't an extra feature at all but a special case of a generic > loop. Which means it is NOT a fundamental language feature. "Repeat N without tracking the loop

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread BartC
On 02/08/2016 15:58, Chris Angelico wrote: On Tue, Aug 2, 2016 at 9:05 PM, BartC wrote: I think the real reason is not willing to admit that the language lacks something that could actually be useful, and especially not to an upstart on usenet who is not even an expert in that

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread Chris Angelico
On Tue, Aug 2, 2016 at 9:05 PM, BartC wrote: > I think the real reason is not willing to admit that the language lacks > something that could actually be useful, and especially not to an upstart on > usenet who is not even an expert in that language. I know what features I miss

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-08-02 Thread BartC
On 31/07/2016 19:58, Terry Reedy wrote: On 7/31/2016 6:18 AM, BartC wrote: repeat N: The benefit is not so much performance, but being able to express something very easily and quickly. The cost of the 'repeat' contraction is that one cannot use the loop variable, either as part of a

Re: Debugging (was Re: Why not allow empty code blocks?)

2016-07-31 Thread Chris Angelico
On Mon, Aug 1, 2016 at 4:58 AM, Terry Reedy wrote: > > As for the original topic: Guido judged that a uniform rule "Compound > statement headers end with ':' and the next line has an additional indent" > would make correct code easier to write and parse and make it visually more

Debugging (was Re: Why not allow empty code blocks?)

2016-07-31 Thread Terry Reedy
On 7/31/2016 6:18 AM, BartC wrote: The costs are near zero: at minimum, a syntactic construct such as: repeat N: that expands to: for _ in range(N): The benefit is not so much performance, but being able to express something very easily and quickly. The cost of the 'repeat' contraction