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 days, and they don't do it by hard-coding > dedicated syntax for each thing you want to optimize. That's very 1970s. Leaving out unneeded parts of a statement is not hand-optimising; it's just being sensible. But actually Python is chock-full of dedicated features designed to allow you to be very productive without writing much code. (Which is handy for a bytecode language as it means a lot of things will execute in native code.) Oddly people are much less keen on dedicated bits of syntax, even if it's a cut-down bit of something that's already there! > Bart, I'm not putting you down for having no users. But your judgement of > the pros and cons of a feature is biased one way because you only have to > please yourself. I'm suggesting ideas that originated in Algol68. Not widely used but not a one-person job either, and it is quite well regarded. (I love the syntax but don't care for the rest of it.) > 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 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!) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
