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

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?)

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?)

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?)

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?)

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?)

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: Why not allow empty code blocks?

On 03/08/2016 23:31, Chris Angelico wrote: On Thu, Aug 4, 2016 at 8:21 AM, BartC wrote: But is this a generic mechanism that works for /any/ .dll file, or does there have to be dedicated support for each of the 60 built-in modules? I'm talking about the former. Frankly, I

Re: Why not allow empty code blocks?

On 04/08/2016 00:25, Paul Rubin wrote: BartC writes: sometimes you try to find a .py import module and it doesn't seem to exist anywhere. (sys.py for example). I would like to see how such references are translated to Lisp. (require 'sys) What does that do? Don't tell me

Re: Why not allow empty code blocks?

BartC writes: > sometimes you try to find a .py import module and it > doesn't seem to exist anywhere. (sys.py for example). > I would like to see how such references are translated to Lisp. (require 'sys) -- https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Thu, Aug 4, 2016 at 8:21 AM, BartC wrote: > But is this a generic mechanism that works for /any/ .dll file, or does > there have to be dedicated support for each of the 60 built-in modules? > > I'm talking about the former. Frankly, I don't want that. Most C APIs are

Re: Why not allow empty code blocks?

On 03/08/2016 22:39, Chris Angelico wrote: On Thu, Aug 4, 2016 at 6:53 AM, BartC wrote: On 03/08/2016 21:12, Chris Angelico wrote: Fairly common approach - and it means you'll never find those .py files. So it's no different from looking for sys.py and not finding it, except

Re: Why not allow empty code blocks?

On Thu, Aug 4, 2016 at 6:53 AM, BartC wrote: > On 03/08/2016 21:12, Chris Angelico wrote: >> >> Fairly common approach - and it means you'll never find those .py >> files. So it's no different from looking for sys.py and not finding >> it, except that in the case of CPython's

Re: Why not allow empty code blocks?

On 03/08/2016 21:12, Chris Angelico wrote: On Thu, Aug 4, 2016 at 4:52 AM, BartC wrote: On 03/08/2016 14:31, Chris Angelico wrote: On Wed, Aug 3, 2016 at 11:23 PM, BartC wrote: On 03/08/2016 09:58, Steven D'Aprano wrote: But sometimes you try to find a

Re: Why not allow empty code blocks?

On Wed, 03 Aug 2016 14:06:06 +, Grant Edwards wrote: > On 2016-08-03, Rustom Mody wrote: > >> The first nokia I used never crashed but could still run out of battery >> And the round-dial landlines of 30 years ago had not even that problem > > Yes, technically, it

Re: Why not allow empty code blocks?

On Thu, Aug 4, 2016 at 4:52 AM, BartC wrote: > On 03/08/2016 14:31, Chris Angelico wrote: >> >> On Wed, Aug 3, 2016 at 11:23 PM, BartC wrote: >>> >>> On 03/08/2016 09:58, Steven D'Aprano wrote: >>> >>> But sometimes you try to find a .py import module and it

Re: Why not allow empty code blocks?

On 03/08/2016 14:31, Chris Angelico wrote: On Wed, Aug 3, 2016 at 11:23 PM, BartC wrote: On 03/08/2016 09:58, Steven D'Aprano wrote: Python is sometimes described as a Lisp with more sensible syntax, so its not surprising that it is relatively simple to translate Python to

Re: Why not allow empty code blocks?

On 2016-08-03, Rustom Mody wrote: > The first nokia I used never crashed but could still run out of > battery And the round-dial landlines of 30 years ago had not even > that problem Yes, technically, it did. Except the batteries were kept elsewhere, and the telco went

Re: Why not allow empty code blocks?

"D'Arcy J.M. Cain" wrote: >On Mon, 01 Aug 2016 00:25:58 +1000 >Gordon Levi wrote: >> "D'Arcy J.M. Cain" wrote: >> >I don't care if you are using carrier pigeon. If you send an email >> >address, make it a valid one. >> >> I admire those

Re: Why not allow empty code blocks?

On Wed, Aug 3, 2016 at 11:23 PM, BartC wrote: > On 03/08/2016 09:58, Steven D'Aprano wrote: > >> Python is sometimes described as a Lisp with more sensible syntax, so its >> not >> surprising that it is relatively simple to translate Python to Lisp and >> visa >> versa. > > >

Re: Why not allow empty code blocks?

On Wed, Aug 3, 2016 at 11:04 PM, BartC wrote: > On 03/08/2016 13:36, Chris Angelico wrote: >> >> On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody >> wrote: >>> >>> There he comes waddling in… Your cute-n-cudly strawman!! >>> A more realistic analogy would be

Re: Why not allow empty code blocks?

On 03/08/2016 09:58, Steven D'Aprano wrote: Python is sometimes described as a Lisp with more sensible syntax, so its not surprising that it is relatively simple to translate Python to Lisp and visa versa. Translating Python would be easier if everything was implemented as Python. But

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

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: Why not allow empty code blocks?

On 03/08/2016 13:36, Chris Angelico wrote: On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody wrote: There he comes waddling in… Your cute-n-cudly strawman!! A more realistic analogy would be phones The cellphones we use today often crash The first nokia I used never crashed

Re: Why not allow empty code blocks?

On Wednesday, August 3, 2016 at 6:08:08 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > > Note: You CAN use python scheme-ishly but few people do that. > > eg here is SICP in python with the first examples pure useful powerful > > functions: > >

Re: Why not allow empty code blocks?

Rustom Mody : > Note: You CAN use python scheme-ishly but few people do that. > eg here is SICP in python with the first examples pure useful powerful > functions: > http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/functions.html#first-example I see nothing there that is

Re: Why not allow empty code blocks?

On Wed, Aug 3, 2016 at 10:16 PM, Rustom Mody wrote: > There he comes waddling in… Your cute-n-cudly strawman!! > A more realistic analogy would be phones > The cellphones we use today often crash > The first nokia I used never crashed but could still run out of battery >

Re: Why not allow empty code blocks?

Rustom Mody : > As I said earlier what they (the MIT profs) seem to be saying is that > the topical relevance of python — a library for making robots — trumps > scheme’s abstract beauty Python is an excellent choice. As far as abstract beauty is concerned, I'm wondering

Re: Why not allow empty code blocks?

On Wednesday, August 3, 2016 at 5:53:44 PM UTC+5:30, Rustom Mody wrote: > On Wednesday, August 3, 2016 at 5:39:25 PM UTC+5:30, Marko Rauhamaa wrote: > > Rustom Mody : > > I don't know who or what you are referring to. > > I put it in the next line! > > > Scheme for beginning programmers could

Re: Why not allow empty code blocks?

On Wednesday, August 3, 2016 at 5:39:25 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > So yes scheme are python have similar underbellies but the culture of > > use is quite different. > > I don't know if there's enough Scheme activity out there to call it a > culture. > > As far as

Re: Why not allow empty code blocks?

On Wednesday, August 3, 2016 at 5:11:23 PM UTC+5:30, Steven D'Aprano wrote: > On Wednesday 03 August 2016 05:22, Paul Rubin wrote: > > >> The Halting Problem is easily solved for Bloop languages: they always > >> halt. > > > > If Bloop is powerful enough to "solve the halting problem" as you > >

Re: Why not allow empty code blocks?

Rustom Mody : > So yes scheme are python have similar underbellies but the culture of > use is quite different. I don't know if there's enough Scheme activity out there to call it a culture. As far as underbellies go, Scheme macros and operators are not first-class. The

Re: Why not allow empty code blocks?

On Wednesday, August 3, 2016 at 1:57:43 PM UTC+5:30, Antoon Pardon wrote: > Op 02-08-16 om 14:29 schreef Rustom Mody: > > So I was talking of 3 very different levels: > > > > 1. print x vs print(x) > > — a difference too petty for me to waste my time with > > > > 2. Procedure vs Function as

Re: Why not allow empty code blocks?

On Wednesday 03 August 2016 05:22, Paul Rubin wrote: >> The Halting Problem is easily solved for Bloop languages: they always >> halt. > > If Bloop is powerful enough to "solve the halting problem" as you > describe, that gives it capabilities that Turing-complete languages > lack. (Of course

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

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: Why not allow empty code blocks?

On Wednesday, August 3, 2016 at 12:53:02 AM UTC+5:30, Paul Rubin wrote: > Steven D'Aprano writes: > > where power is defined (rather fuzzily) as the expressiveness > > of the language, how easy it is for the programmer to read, write and > > maintain code, how efficient/fast you can implement it,

Re: Why not allow empty code blocks?

Op 02-08-16 om 14:29 schreef Rustom Mody: > So I was talking of 3 very different levels: > > 1. print x vs print(x) > — a difference too petty for me to waste my time with > > 2. Procedure vs Function as something very necessary for beginner > thinking-ontology which Pascal gets right > > 3. The

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

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?)

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?)

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?)

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?)

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?)

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: Why not allow empty code blocks?

Steven D'Aprano wrote: > It could be, but won't be. Outside of a very few tiny niches, including > Squeak which is designed for children, such user-interfaces are far too > cumbersome to ever get widespread use. Unfortunately, many people use LabView in my field...

Re: Why not allow empty code blocks?

On 2016-08-02, BartC wrote: > On 02/08/2016 18:54, Steven D'Aprano wrote: >> On Wed, 3 Aug 2016 02:56 am, BartC wrote: >> >>> (And I expect that next they will eliminate languages altogether. All >>> you need is some way of specifying a sequence of calls to library >>> functions

Re: Why not allow empty code blocks?

Steven D'Aprano writes: > where power is defined (rather fuzzily) as the expressiveness > of the language, how easy it is for the programmer to read, write and > maintain code, how efficient/fast you can implement it, etc. Scheme guru Matthias Felleisen takes a stab

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

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: Why not allow empty code blocks?

On 02/08/2016 18:54, Steven D'Aprano wrote: On Wed, 3 Aug 2016 02:56 am, BartC wrote: (And I expect that next they will eliminate languages altogether. All you need is some way of specifying a sequence of calls to library functions and sprinkling around some control statements; That would be

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

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: Why not allow empty code blocks?

On Wed, Aug 3, 2016 at 3:54 AM, Steven D'Aprano wrote: > On Wed, 3 Aug 2016 02:56 am, BartC wrote: > >> (And I expect that next they will eliminate languages altogether. All >> you need is some way of specifying a sequence of calls to library >> functions and

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

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: Why not allow empty code blocks?

On Tue, 2 Aug 2016 11:28 pm, Rustom Mody 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. > > And earlier you said: > >> But

Re: Why not allow empty code blocks?

On Wed, 3 Aug 2016 02:56 am, BartC wrote: > (And I expect that next they will eliminate languages altogether. All > you need is some way of specifying a sequence of calls to library > functions and sprinkling around some control statements; That would be called "a language". > it could be >

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

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: Why not allow empty code blocks?

On 02/08/2016 14:28, Rustom Mody 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. However a case may be made that syntax is one of the

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

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: Why not allow empty code blocks?

> 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. And earlier you said: > But dedicated forms (even if they just map to 'while' or 'for')

Re: Why not allow empty code blocks?

On Tuesday, August 2, 2016 at 4:01:25 PM UTC+5:30, Antoon Pardon wrote: > Op 30-07-16 om 18:15 schreef Rustom Mody: > > > > The more general baby that is significant is that beginners should have > > it easy to distinguish procedure and function and python does not naturally > > aid that. print

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

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: Why not allow empty code blocks?

Op 30-07-16 om 18:15 schreef Rustom Mody: > > The more general baby that is significant is that beginners should have > it easy to distinguish procedure and function and python does not naturally > aid that. print was something procedure-ish in python2 but the general > notion being > absent is

Re: Why not allow empty code blocks?

Op 30-07-16 om 05:49 schreef Steven D'Aprano: > On Sat, 30 Jul 2016 04:32 am, Antoon Pardon wrote: > > > Perhaps its *you* who doesn't understand. The subject line talks > about "empty code blocks", and Bart has suggested that instead of having to > write > > ... > > So now you're changing your

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 11:12:30 UTC+1, Steven D'Aprano wrote: > On Monday 01 August 2016 18:05, bart4...@gmail.com wrote: > No offense intended Bart, but for all we know every single one of your > benchmarks are faked, your interpreters are buggy pieces of garbage, and for > all your

Re: Why not allow empty code blocks?

Gordon Levi : > In contrast, your valid email address will become the target of many > spam emails even if you manage to block them. It will also be used as > the source of spam so somebody at vex.net may be fooled into believing > that they are receiving a proper email.

Re: Why not allow empty code blocks?

"D'Arcy J.M. Cain" wrote: >On Sun, 31 Jul 2016 11:53:47 -0400 >"D'Arcy J.M. Cain" wrote: >> On Mon, 01 Aug 2016 00:25:58 +1000 >> On the other hand I have no throwaway accounts. Every address I use >> is a primary one. I have all sorts of methods to block spam.

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 10:50:20 UTC+1, alister wrote: > Actually the more you make these claims the more I think you are > suffering from NIH (Not Invented Here) syndrome. That's not surprising. I started out developing hardware such as microprocessor boards and video displays. My

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 11:12:30 UTC+1, Steven D'Aprano wrote: > On Monday 01 August 2016 18:05, bart4...@gmail.com wrote: > > > You think that my nearly 30 years' experience of designing interpreted > > languages and writing fast bytecode interpreters doesn't make my opinions > > have any more

Re: Why not allow empty code blocks?

On Monday 01 August 2016 18:05, bart4...@gmail.com wrote: > You think that my nearly 30 years' experience of designing interpreted > languages and writing fast bytecode interpreters doesn't make my opinions > have any more merit, that's fine. If you are the only one who has ever seen or used

Re: Why not allow empty code blocks?

On Mon, 01 Aug 2016 01:05:53 -0700, bart4858 wrote: > On Monday, 1 August 2016 01:33:37 UTC+1, Chris Angelico wrote: >> On Mon, Aug 1, 2016 at 10:21 AM, wrote: > >> > However I do 'drive' as I've been programming for decades. And I can >> > have an opinion about a model of

Re: Why not allow empty code blocks?

On Mon, 01 Aug 2016 09:49:46 +1000, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 9:43 AM, wrote: >> On Sunday, 31 July 2016 21:01:52 UTC+1, Michael Torrie wrote: >> >>> That said, I wish he'd stop posting his arguments here on this list as >>> he clearly doesn't use

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 01:33:37 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 10:21 AM, wrote: > > However I do 'drive' as I've been programming for decades. And I can have > > an opinion about a model of car that I don't normally drive. An opinion > > which you

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 01:22:02 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 10:11 AM, wrote: > > (128MB or 128KB? In the 1980s we were all running in 64KB to 640KB of > > memory. 128MB might be what a well-endowed mainframe might have had!) > > Yes, and we

Re: Why not allow empty code blocks?

On Mon, Aug 1, 2016 at 12:09 PM, Paul Rubin wrote: > Chris Angelico writes: >> But out of 20MB, I easily had *space* for a compiler. The problem was >> compilation time. I could mess around in BASIC with reasonable >> turnaround times; I could mess

Re: Why not allow empty code blocks?

Chris Angelico writes: > But out of 20MB, I easily had *space* for a compiler. The problem was > compilation time. I could mess around in BASIC with reasonable > turnaround times; I could mess around in DEBUG with excellent > turnaround times. Doing even the tiniest work in C

Re: Why not allow empty code blocks?

On Sunday 31 July 2016 12:39:00 Dennis Lee Bieber wrote: > On Mon, 01 Aug 2016 01:31:42 +1000, Steven D'Aprano > > > declaimed the following: > >And you know what? That's fine. It's *good* that there are language > >designers with different ideas of what's valuable. That

Re: Why not allow empty code blocks?

On Mon, Aug 1, 2016 at 10:55 AM, Paul Rubin wrote: > Chris Angelico writes: >> Yes, and we didn't have Python then. When I had a computer with 640KB >> of memory, my options were (1) BASIC or (2) 8086 assembly language, >> using DEBUG.EXE and its

Re: Why not allow empty code blocks?

Chris Angelico writes: > Yes, and we didn't have Python then. When I had a computer with 640KB > of memory, my options were (1) BASIC or (2) 8086 assembly language, > using DEBUG.EXE and its mini-assembler. Later on (much much later), I > added C to the available languages, but

Re: Why not allow empty code blocks?

On Mon, Aug 1, 2016 at 10:21 AM, wrote: > On Monday, 1 August 2016 00:50:09 UTC+1, Chris Angelico wrote: >> On Mon, Aug 1, 2016 at 9:43 AM, wrote: >> > On Sunday, 31 July 2016 21:01:52 UTC+1, Michael Torrie wrote: >> > >> >> That said, I wish he'd stop

Re: Why not allow empty code blocks?

On Monday, 1 August 2016 00:50:09 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 9:43 AM, wrote: > > On Sunday, 31 July 2016 21:01:52 UTC+1, Michael Torrie wrote: > > > >> That said, I wish he'd stop posting his arguments here on this list as > >> he clearly doesn't use

Re: Why not allow empty code blocks?

On Mon, Aug 1, 2016 at 10:11 AM, wrote: >> In that same thread, one of the lead Python devs Victor Stinner talks about >> some of his work on embedded devices where he has a hard limit of 128MB for >> *everything*: boot loader, kernel, OS, applications, etc. > > (128MB or

Re: Why not allow empty code blocks?

On Sunday, 31 July 2016 16:31:56 UTC+1, Steven D'Aprano wrote: > On Sun, 31 Jul 2016 08:18 pm, BartC wrote: > The whole point of an optimizing compiler is that you don't have to detect > patterns yourself. The compiler does it. There's a whole science to writing > optimizing compilers these

Re: Why not allow empty code blocks?

On Mon, Aug 1, 2016 at 9:43 AM, wrote: > On Sunday, 31 July 2016 21:01:52 UTC+1, Michael Torrie wrote: > >> That said, I wish he'd stop posting his arguments here on this list as >> he clearly doesn't use Python for anything, and hasn't used Python for >> any real amount of

Re: Why not allow empty code blocks?

On Sunday, 31 July 2016 21:01:52 UTC+1, Michael Torrie wrote: > That said, I wish he'd stop posting his arguments here on this list as > he clearly doesn't use Python for anything, and hasn't used Python for > any real amount of coding. He has no vested interest in Python so why > should his

Re: Why not allow empty code blocks?

On 07/31/2016 10:04 AM, D'Arcy J.M. Cain wrote: > On Sun, 31 Jul 2016 11:53:47 -0400 > "D'Arcy J.M. Cain" wrote: >> On Mon, 01 Aug 2016 00:25:58 +1000 >> On the other hand I have no throwaway accounts. Every address I use >> is a primary one. I have all sorts of methods to block

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

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

Re: Why not allow empty code blocks?

On 31 Jul 2016, at 19:22, Steven D'Aprano wrote: On Mon, 1 Aug 2016 12:25 am, Gordon Levi wrote: I admire those who use a valid email address on Usenet but it is an open invitation for spammers. I doubt if there is anybody who uses their primary email address. Spammers have moved on from

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

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

Re: Why not allow empty code blocks?

Steven D'Aprano writes: > There's a real mystery why concatenative/postfix languages have > received so little attention from the academic community compared to > prefix languages. There's a wiki with lots of info: http://www.concatenative.org This LTU thread and the

Re: Why not allow empty code blocks?

On Mon, 1 Aug 2016 12:25 am, Gordon Levi wrote: > I admire those who use a valid email address on Usenet but it is an > open invitation for spammers. I doubt if there is anybody who uses > their primary email address. Spammers have moved on from Usenet. Those few that haven't are

Re: Why not allow empty code blocks?

On Sun, 31 Jul 2016 05:39 pm, Gregory Ewing wrote: > Steven D'Aprano wrote: >> It has always perplexed me that Lisp's prefix notation is held up as >> the /sine qua non/ of elegance and power, while Forth is ignored if not >> ridiculed. > > The reason Lisp is easier to program in than Forth is

Re: Why not allow empty code blocks?

Gordon Levi : > I admire those who use a valid email address on Usenet but it is an > open invitation for spammers. I doubt if there is anybody who uses > their primary email address. Feel free to keep admiring me. Marko --

Re: Why not allow empty code blocks?

"D'Arcy J.M. Cain" writes: > So I have to examine every address I reply to or deal with the bounce > message later. Way to move your spam problem to someone else. It's not entirely about spam. I stopped posting addresses because people kept insisting on replying to my posts by

Re: Why not allow empty code blocks?

Ian Kelly writes: > What does JSON have to do with LISP? JSON is a crappy form of S-expressions. -- https://mail.python.org/mailman/listinfo/python-list

Re: Why not allow empty code blocks?

On Sun, 31 Jul 2016 11:53:47 -0400 "D'Arcy J.M. Cain" wrote: > On Mon, 01 Aug 2016 00:25:58 +1000 > On the other hand I have no throwaway accounts. Every address I use > is a primary one. I have all sorts of methods to block spam. None of > those methods involves moving my spam

Re: Why not allow empty code blocks?

On Mon, 01 Aug 2016 00:25:58 +1000 Gordon Levi wrote: > "D'Arcy J.M. Cain" wrote: > >I don't care if you are using carrier pigeon. If you send an email > >address, make it a valid one. > > I admire those who use a valid email address on Usenet but it is

Re: Why not allow empty code blocks?

On Sun, 31 Jul 2016 08:18 pm, BartC wrote: > On 31/07/2016 03:10, Steven D'Aprano wrote: >> On Sun, 31 Jul 2016 04:46 am, BartC wrote: > >>> No named loop variable to invent, create, maintain, and destroy. No >>> range object to create, destroy etc. If you're looking for ways for a >>> language

Re: Why not allow empty code blocks?

"D'Arcy J.M. Cain" wrote: >On Sat, 30 Jul 2016 16:14:18 +0100 >BartC wrote: >> > By the way, the last time I replied to you it went to the list but >> > your address bounced. Was that a glitch or are you using an >> > invalid address in a mailing list? >> >> Do

Re: Why not allow empty code blocks?

On Sun, Jul 31, 2016 at 1:51 AM, Marko Rauhamaa wrote: > It is quite astounding how Lisp is steadily being reinvented by the > down-to-earth programming community. It was famously observed by Paul > Graham in 2002 (http://www.paulgraham.com/icad.html>). The > evolution has kept

Re: Why not allow empty code blocks?

On 31/07/2016 03:10, Steven D'Aprano wrote: On Sun, 31 Jul 2016 04:46 am, BartC wrote: No named loop variable to invent, create, maintain, and destroy. No range object to create, destroy etc. If you're looking for ways for a language to be more efficient, then why disregard this possibility?

Re: Why not allow empty code blocks?

Marko Rauhamaa writes: > Gregory Ewing : >> If Forth had come out of a computer science department and Lisp had >> been invented by an astronomer, Lisp would still be the easier >> language to use. > > It is quite astounding how Lisp is steadily

Re: Why not allow empty code blocks?

Gregory Ewing writes: > The reason Lisp is easier to program in than Forth is not > because of prefix vs. postfix. It's because in Lisp a function > call is syntactically grouped together with its arguments, > whereas in Forth it's not. Forth requires you to mentally

Re: Why not allow empty code blocks?

Gregory Ewing : > If Forth had come out of a computer science department and Lisp had > been invented by an astronomer, Lisp would still be the easier > language to use. It is quite astounding how Lisp is steadily being reinvented by the down-to-earth programming

  1   2   3   >