Re: Looping [was Re: Python and the need for speed]

On Wed, 11 Oct 2017 10:57 pm, Stefan Ram wrote: > FWIW, in is book "Touch of Class" (2009) Bertrand Meyer writes: > > |Such instructions are just the old goto in sheep's clothing. > |Treat them the same way as the original: > | > |/Touch of Methodology/: > | Sticking to one-entry, one-exit

Re: Static typing [was Re: Python and the need for speed]

Gregory Ewing writes: > A JIT compiler works by observing the actual values To be pedantic, that's called a "tracing JIT". Other runtime code generation is also frequently called JIT compilation even when it's fairly stupid combining of assembly code templates, or

Re: Looping [was Re: Python and the need for speed]

Chris Angelico writes: > while True: > c = sys.stdin.read(1) > if not c: break > if c.isprintable(): text += c > elif c == "\x08": text = text[:-1] > # etc > Can you write _that_ as a do-while? I prefer to write that sort of thing with iterators: for c in

Re: Python and the need for speed

On 19/04/2017 17:23, Marko Rauhamaa wrote: bartc : Enough works in that 'pcc' project, in terms of file i/o, that it can still run plenty of useful programs, such as compilers. This might have come up before, but do you have a language specification somewhere? (Nothing

Re: Python and the need for speed

bartc : > Enough works in that 'pcc' project, in terms of file i/o, that it can > still run plenty of useful programs, such as compilers. This might have come up before, but do you have a language specification somewhere? Marko --

Re: Python and the need for speed

On 19/04/2017 15:35, Chris Angelico wrote: On Wed, Apr 19, 2017 at 11:46 PM, bartc wrote: You'd be surprised how easy it is to be non-OS-neutral. I misread that as 'easy to be OS-neutral'. If I turn it around, you're saying it is easy to be OS-specific. But we know that!

Re: Python and the need for speed

On Wed, Apr 19, 2017 at 11:46 PM, bartc wrote: >> You'd be surprised how easy it is to be non-OS-neutral. > > It's not so simple. By OS-neutral I mean code that doesn't depend on special > features of either OS (Ie. Windows and Linux). Not conditional code that > does either

Re: Python and the need for speed

On 19/04/2017 12:27, Chris Angelico wrote: On Wed, Apr 19, 2017 at 8:33 PM, bartc wrote: [Warning: this is nothing to do with Python.] My interpreter is on github as /one/ C source file (a link would be inappropriate here). People can compile it with -O3 or -O2 if they

Re: Looping [was Re: Python and the need for speed]

Op 16-04-17 om 19:07 schreef Terry Reedy: > On 4/16/2017 11:35 AM, Michael Torrie wrote: >> On 04/16/2017 07:57 AM, bartc wrote: >>> But people just don't want it. >>> >>> /That/ is what surprises me, when people reject things that to me are >>> no-brainers. > > Whereas to me, it is a no-brainer

Re: Python and the need for speed

Chris Angelico : > On Wed, Apr 19, 2017 at 8:33 PM, bartc wrote: > You'd be surprised how easy it is to be non-OS-neutral. Have you > compiled it on the three major platforms of today (Lin/Win/Mac)? Generally, I don't try to be OS-neutral because 1. I need

Re: Python and the need for speed

On Wed, Apr 19, 2017 at 8:33 PM, bartc wrote: > My interpreter is on github as /one/ C source file (a link would be > inappropriate here). People can compile it with -O3 or -O2 if they wish. > It's a bit simpler than building CPython, and OS-neutral; that was > deliberate. Then

Re: Python and the need for speed

On 19/04/2017 01:07, Erik wrote: On 19/04/17 00:33, bartc wrote: [Talking about an interpreter that is /not/ for Python] With the sort of lower level programs I write (in another dynamic language not Python), such an assembly layer improved performance 2-3 times over using 100% HLL compiled

Re: Python and the need for speed

On 19/04/17 00:33, bartc wrote: So that's 'label-pointers' which I assume must correspond to computed goto. Yes - just different terminology. Being able to take the address of a label and "goto address" rather than "goto label". (I don't know why they should be faster than a switch; they

Re: Python and the need for speed

On 19/04/2017 00:19, Gregory Ewing wrote: bartc wrote: Another optimisation for something like ADD, was to to check for very common types such as INT, and deal with those locally. And then you're on the path to writing a JIT compiler. If you can identify such cases, you might as well

Re: Static typing [was Re: Python and the need for speed]

Steve D'Aprano wrote: You seem to be describing a *tracing JIT* compiler. Well, yes, but it seems to me that a JIT compiler that *doesn't* use tracing is just an AOT compiler that you happen to run immediately before executing the program. Cython doesn't do any of that -- it's just a plain,

Re: Python and the need for speed

On 18/04/2017 23:33, Erik wrote: On 18/04/17 11:30, bartc wrote: On 18/04/2017 10:32, Erik wrote: the improvements over the original huge switch() to dispatch the bytecodes to the correct handler appear to have made this type of optimization less effective. What did they do to it, and on

Re: Python and the need for speed

On 19/04/17 00:08, Gregory Ewing wrote: Erik wrote: When considering special-casing this opcode sequence, remember that in-place operations can be performed on anonymous objects (i.e., those referenced by a collection and not bound directly to a namespace): I think this means you would want

Re: Python and the need for speed

On 19/04/2017 00:08, Gregory Ewing wrote: Erik wrote: When considering special-casing this opcode sequence, remember that in-place operations can be performed on anonymous objects (i.e., those referenced by a collection and not bound directly to a namespace): I think this means you would want

Re: Python and the need for speed

bartc wrote: But another problem was, there /are/ no simple byte-codes in CPython! Yes, that's the crux of the whole thing. It's the reason it's so hard to compile Python to anything that runs significantly faster than interpreted code. Another optimisation for something like ADD, was to to

Re: Python and the need for speed

Erik wrote: When considering special-casing this opcode sequence, remember that in-place operations can be performed on anonymous objects (i.e., those referenced by a collection and not bound directly to a namespace): I think this means you would want multiple versions of the +=1 opcode:

Re: Looping [was Re: Python and the need for speed]

Ben Bacarisse wrote: I fond the proportion on while True: loops surprising. Is there something about Python that encourages that kind of loop? Maybe because for-loops take care of most of the ordinary cases in Python, leaving while-loops to cover the weird ones, many of which need one or

Re: Python and the need for speed

On 18/04/17 11:30, bartc wrote: On 18/04/2017 10:32, Erik wrote: the improvements over the original huge switch() to dispatch the bytecodes to the correct handler appear to have made this type of optimization less effective. What did they do to it, and on which version? It's the computed

Re: Static typing [was Re: Python and the need for speed]

On Tue, 18 Apr 2017 03:43 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> I'm not sure why the Cython devs maintain this is not a JIT compiler. >> Perhaps I misunderstand something. > > A JIT compiler works by observing the actual values taken on > by variables at run time, and if it notices

Re: Python and the need for speed

On 18/04/2017 10:32, Erik wrote: FWIW, I spent some time about a year ago looking at things like this (small improvements to the peephole optimizer which allowed certain very common sequences to be folded into a (new) opcode which in turn allowed other optimizations to avoid branching). The

Re: Python and the need for speed

On 13/04/17 18:50, MRAB wrote: On 2017-04-13 09:08, Steven D'Aprano wrote: On Wed, 12 Apr 2017 16:30:38 -0700, bart4858 wrote: Is it possible to skip the STORE_NAME op-code? If you knew *for sure* that the target (x) was a mutable object which implemented += using an in- place mutation, then

Re: Looping [was Re: Python and the need for speed]

Christian Gollwitzer writes: > Am 18.04.17 um 08:21 schrieb Chris Angelico: >> On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer >> wrote: >>> Am 18.04.17 um 02:18 schrieb Ben Bacarisse: >>> Thanks (and to Grant). IO seems to be the canonical example. Where some

Re: Looping [was Re: Python and the need for speed]

Am 18.04.17 um 08:21 schrieb Chris Angelico: On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote: Am 18.04.17 um 02:18 schrieb Ben Bacarisse: Thanks (and to Grant). IO seems to be the canonical example. Where some languages would force one to write c =

Re: Looping [was Re: Python and the need for speed]

Christian Gollwitzer : > Am 18.04.17 um 02:18 schrieb Ben Bacarisse: >> Python opts for >> >> while True: >> c = sys.stdin.read(1) >> if c != ' ': break > > This loop would be the archetypical do..while or repeat...until to me. > > do > c = sys.stdin.read(1) >

Re: Looping [was Re: Python and the need for speed]

On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote: > Am 18.04.17 um 02:18 schrieb Ben Bacarisse: > >> Thanks (and to Grant). IO seems to be the canonical example. Where >> some languages would force one to write >> >> c = sys.stdin.read(1) >> while c == ' ': >>

Re: Looping [was Re: Python and the need for speed]

Am 18.04.17 um 02:18 schrieb Ben Bacarisse: Thanks (and to Grant). IO seems to be the canonical example. Where some languages would force one to write c = sys.stdin.read(1) while c == ' ': c = sys.stdin.read(1) Python opts for while True: c = sys.stdin.read(1) if c !=

Re: Static typing [was Re: Python and the need for speed]

Steve D'Aprano wrote: I'm not sure why the Cython devs maintain this is not a JIT compiler. Perhaps I misunderstand something. A JIT compiler works by observing the actual values taken on by variables at run time, and if it notices that a particular variable seems to always have a particular

Re: Looping [was Re: Python and the need for speed]

On Tuesday, April 18, 2017 at 2:09:19 AM UTC+1, Paul Rubin wrote: > Ben Bacarisse writes: > > ? I get "AttributeError: 'itertools.dropwhile' object has no attribute > > 'next'" from your example. > > Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened. > Maybe something went

Re: Looping [was Re: Python and the need for speed]

Ben Bacarisse : > Python opts for > > while True: > c = sys.stdin.read(1) > if c != ' ': break I opt for that in C and bash as well. In fact, when I start writing a loop, I first type: while True: Once it is done, I might notice that the loop

Re: Static typing [was Re: Python and the need for speed]

On Mon, 17 Apr 2017 08:52 pm, Steve D'Aprano wrote: > but research does continue into using gradual typing for optimizations: > > http://dl.acm.org/citation.cfm?id=2069175 Another interesting research project into speeding up Jython using type hints:

Re: Looping [was Re: Python and the need for speed]

Gregory Ewing : > Marko Rauhamaa wrote: >> What I notice in my numbers is that about one half of my while loops >> are "while True", and about a third of my loops are while loops. > > Out of curiosity, what proportion of your 'while True' loops are > infinite? (I.e.

Re: Looping [was Re: Python and the need for speed]

On Tue, Apr 18, 2017 at 1:37 AM, MRAB wrote: > In Python 3 it's: > > c = next(itertools.dropwhile( > lambda c: c==' ', > iter(lambda: sys.stdin.read(1),None) > )) iter's sentinel should be an empty string. --

Re: Looping [was Re: Python and the need for speed]

On 2017-04-18 02:09, Paul Rubin wrote: Ben Bacarisse writes: ? I get "AttributeError: 'itertools.dropwhile' object has no attribute 'next'" from your example. Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened. Maybe something went wrong with my

Re: Looping [was Re: Python and the need for speed]

Ben Bacarisse writes: > ? I get "AttributeError: 'itertools.dropwhile' object has no attribute > 'next'" from your example. Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened. Maybe something went wrong with my paste. Oh well. > Coming from the lazy

Re: Looping [was Re: Python and the need for speed]

Paul Rubin writes: > Ben Bacarisse writes: >> c = sys.stdin.read(1) >> while c == ' ': >> c = sys.stdin.read(1) (for the record: I was not suggesting this was how you'd do it but how you'd be forced to do it in some languages) > c =

Re: Looping [was Re: Python and the need for speed]

On 18/04/2017 01:23, Paul Rubin wrote: Ben Bacarisse writes: c = sys.stdin.read(1) while c == ' ': c = sys.stdin.read(1) c = itertools.dropwhile( lambda c: c==' ', iter(lambda: sys.stdin.read(1),None) ).next() I tried this but it doesn't like

Re: Looping [was Re: Python and the need for speed]

Marko Rauhamaa writes: > Ben Bacarisse : > >> Marko Rauhamaa writes: >>> What I notice in my numbers is that about one half of my while loops >>> are "while True", and about a third of my loops are while loops. >> >> I fo[u]nd the

Re: Looping [was Re: Python and the need for speed]

Ben Bacarisse writes: > c = sys.stdin.read(1) > while c == ' ': > c = sys.stdin.read(1) c = itertools.dropwhile( lambda c: c==' ', iter(lambda: sys.stdin.read(1),None) ).next() -- https://mail.python.org/mailman/listinfo/python-list

Re: Looping [was Re: Python and the need for speed]

Marko Rauhamaa wrote: What I notice in my numbers is that about one half of my while loops are "while True", and about a third of my loops are while loops. Out of curiosity, what proportion of your 'while True' loops are infinite? (I.e. no break, return or raise in the loop.) -- Greg --

Re: Static typing [was Re: Python and the need for speed]

Steve D'Aprano writes: > On the other hand, there's Cython. Cython claims *not* to be a JIT compiler, One of the uses of "JIT compiler" these days is what's sometimes called a tracing JIT, like PyPy or LuaJIT or the Javascript flavor-of-the-week. That means it

Re: Looping [was Re: Python and the need for speed]

On 2017-04-17, Ben Bacarisse wrote: > Marko Rauhamaa writes: > >> Terry Reedy : >> >>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote: Here's statistics from a medium-sized project of mine: while True:34

Re: Looping [was Re: Python and the need for speed]

On 17 April 2017 at 04:00, Steve D'Aprano wrote: > On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote: > >> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano >> declaimed the following: >> >>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:

Re: Looping [was Re: Python and the need for speed]

Ben Bacarisse : > Marko Rauhamaa writes: >> What I notice in my numbers is that about one half of my while loops >> are "while True", and about a third of my loops are while loops. > > I fo[u]nd the proportion on while True: loops surprising. Is there >

Re: Looping [was Re: Python and the need for speed]

On 17/04/2017 19:02, Ben Bacarisse wrote: Marko Rauhamaa writes: Terry Reedy : On 4/17/2017 3:11 AM, Marko Rauhamaa wrote: Here's statistics from a medium-sized project of mine: while True:34 while : 39 for ... in ...: 158

Re: Looping [was Re: Python and the need for speed]

Marko Rauhamaa writes: > Terry Reedy : > >> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote: >>> Here's statistics from a medium-sized project of mine: >>> >>>while True:34 >>>while : 39 >>>for ... in ...: 158 >> >> As I posted

Re: Looping [was Re: Python and the need for speed]

Terry Reedy : > On 4/17/2017 3:11 AM, Marko Rauhamaa wrote: >> Here's statistics from a medium-sized project of mine: >> >>while True:34 >>while : 39 >>for ... in ...: 158 > > As I posted previously, the ratio of for-loops in the stdlib is about

Re: Looping [was Re: Python and the need for speed]

On 4/17/2017 3:11 AM, Marko Rauhamaa wrote: Gregory Ewing : bartc wrote: Most of my loops start off as endless loops, until I can determine the actual terminating condition, and where it best goes. Interesting. My experience is quite different. Most of the loops

Re: Static typing [was Re: Python and the need for speed]

On Mon, 17 Apr 2017 04:18 pm, Paul Rubin wrote: > Steve D'Aprano writes: >> Since it is *optional*, it is only a hint, not a fact. You can tell the >> compiler that you believe that n will be an int, but it's not guaranteed. > > The runtime could check at the entry

Re: Static typing [was Re: Python and the need for speed]

On Sun, 16 Apr 2017 02:27 pm, Steve D'Aprano wrote: > Are you aware that optional static typing CANNOT be used for optimization? I think I've over-stated that. Considerably. In other words, I was wrong. As Steve Yegge points out, dynamic languages like Smalltalk and Lisp were, back in the

Re: Moderating the list [was: Python and the need for speed]

On Thursday, April 13, 2017 at 10:31:22 AM UTC+1, Tim Golden wrote: > On 13/04/2017 03:39, Jason Friedman wrote: > >> > >> However, it's simply a technical fact: the thing which we moderate is the > >>> mailing list. We can control which posts make it through from the > >>> newsgroup > >>> by

Re: Looping [was Re: Python and the need for speed]

Gregory Ewing : > bartc wrote: >> Most of my loops start off as endless loops, until I can determine >> the actual terminating condition, and where it best goes. > > Interesting. My experience is quite different. Most of the loops I > write start off with me thinking

Re: Static typing [was Re: Python and the need for speed]

Steve D'Aprano writes: > Since it is *optional*, it is only a hint, not a fact. You can tell the > compiler that you believe that n will be an int, but it's not guaranteed. The runtime could check at the entry to the function that n is an int, and then it wouldn't

Re: Static typing [was Re: Python and the need for speed]

On Mon, 17 Apr 2017 05:16 am, bartc wrote: > But it was OK for Steve to 'win' the benchmark by substituting my test > code with something only vaguely related, and much simpler? Okay, you're now being obnoxious, and telling lies about me. What I said was "FOR WHAT IT'S WORTH [emphasis added],

Re: Looping [was Re: Python and the need for speed]

On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote: > On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano > declaimed the following: > >>On Sun, 16 Apr 2017 11:57 pm, bartc wrote: >> >>> But people just don't want it. >> >>Damn straight. Now you get it. It's not

Re: Looping [was Re: Python and the need for speed]

bartc wrote: > - describing the various syntax forms; > - explaining how they differ; > - tutorials for beginners showing each form; And you don't have to explain how an endless loop should be written as 'while True', meanwhile advising against using 'while 1'? You don't have to mention

Re: Looping [was Re: Python and the need for speed]

On 16/04/2017 19:42, Chris Angelico wrote: On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote: Here is a function from some old CPython source that appears to be something to do with While statements: static int validate_while(node *tree) { ... Look, no comments! Are you going to

Re: Static typing [was Re: Python and the need for speed]

On Mon, Apr 17, 2017 at 5:16 AM, bartc wrote: > On 16/04/2017 20:00, Chris Angelico wrote: >> >> On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote: > > >> Sure! If all you care about is winning benchmarks, > > > The benchmarks should be about comparing things. But

Re: Static typing [was Re: Python and the need for speed]

On 16/04/2017 20:00, Chris Angelico wrote: On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote: Sure! If all you care about is winning benchmarks, The benchmarks should be about comparing things. But they have to be like for like. Since this was about the effects of type

Re: Static typing [was Re: Python and the need for speed]

On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote: >> >> For what it's worth, on my machine (2GB RAM and 1.2GHz CPU) I can add up >> 100 >> million ints in 14 seconds: >> >> py> with Stopwatch(): >> ... sum(range(1)) >> ... >> 49995000 >> time taken: 14.032116

Re: Static typing [was Re: Python and the need for speed]

On 16/04/2017 18:13, Steve D'Aprano wrote: On Mon, 17 Apr 2017 02:20 am, justin walters wrote: On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote: What were the results with Python on your machine? Well, at first I tried to implement it with a generator. I gave up on waiting

Re: Looping [was Re: Python and the need for speed]

On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote: > Here is a function from some old CPython source that appears to be something > to do with While statements: > > static int > validate_while(node *tree) > { > int nch = NCH(tree); > int res = (validate_ntype(tree, while_stmt)

Re: Looping [was Re: Python and the need for speed]

On 16/04/2017 17:30, Steve D'Aprano wrote: On Sun, 16 Apr 2017 10:06 pm, bartc wrote: (The 30 Loc figure is with support for loops /in general/ already in place, and is for /adding/ a new loop statement, in this case 'while') What part of *testing* and *documenting* do you not understand?

Re: Looping [was Re: Python and the need for speed]

On Mon, 17 Apr 2017 03:00 am, Rustom Mody wrote: > BTW I regard Steven's long list of things that youve missed such as > regression tests, docs etc to be somewhat off the mark > To see that try this experiment: > Just add a feature to python that matters to you along with all these >

Re: Static typing [was Re: Python and the need for speed]

On Mon, 17 Apr 2017 02:20 am, justin walters wrote: > On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote: > >> What were the results with Python on your machine? > > > > Well, at first I tried to implement it with a generator. I gave up on > waiting for the program to complete >

Re: Looping [was Re: Python and the need for speed]

On 4/16/2017 11:35 AM, Michael Torrie wrote: On 04/16/2017 07:57 AM, bartc wrote: But people just don't want it. /That/ is what surprises me, when people reject things that to me are no-brainers. Whereas to me, it is a no-brainer that we are better off *without* multiple while/loop

Re: Looping [was Re: Python and the need for speed]

On Sunday, April 16, 2017 at 7:27:49 PM UTC+5:30, bartc wrote: > Technically, adding this one feature to Python /is/ trivial, ^ You are not paying attention bart and I am not likely to pursue this beyond this post. I tried to say as are others that the substantive reasons to reject a

Re: Looping [was Re: Python and the need for speed]

On Sun, 16 Apr 2017 11:57 pm, bartc wrote: > Yet countless other, far more elaborate features /are/ added all the time. Indeed. Because they are needed. Because they add functionality that Python doesn't already have, or seriously improves the interface to that functionality. > Technically,

Re: Looping [was Re: Python and the need for speed]

On Sun, 16 Apr 2017 10:06 pm, bartc wrote: > On 16/04/2017 03:51, Steve D'Aprano wrote: >> On Sat, 15 Apr 2017 10:17 pm, bartc wrote: > >>> Yes, I'm constantly surprised at this, as such syntax has a very low >>> cost (in my last compiler, supporting 'while' for example only added 30 >>> lines

Re: Static typing [was Re: Python and the need for speed]

On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote: > What were the results with Python on your machine? Well, at first I tried to implement it with a generator. I gave up on waiting for the program to complete after about 6 minutes. After using your code almost exactly I get: >>>

Re: Looping [was Re: Python and the need for speed]

On 16/04/2017 15:22, Chris Angelico wrote: On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote: Technically, adding this one feature to Python /is/ trivial, for example, allowing while: as a synonym for while True:, but preferably using a new keyword such as loop. Nothing else needs

Re: Static typing [was Re: Python and the need for speed]

On 16/04/2017 16:00, justin walters wrote: On Sun, Apr 16, 2017 at 3:55 AM, bartc wrote: Example C of the same silly program in Python: def add(a,b): return a+b def testfn(): sum=a=b=0 for i in range(1): sum += add(a,b) a += 1 b

Re: Looping [was Re: Python and the need for speed]

On 04/16/2017 07:57 AM, bartc wrote: > But people just don't want it. > > /That/ is what surprises me, when people reject things that to me are > no-brainers. I simply don't care about these missing loop constructs. Python works great for what I use it for, and apparently works well for many

Re: Static typing [was Re: Python and the need for speed]

On Sun, Apr 16, 2017 at 3:55 AM, bartc wrote: > Example C of the same silly program in Python: > > def add(a,b): > return a+b > > def testfn(): > sum=a=b=0 > for i in range(1): > sum += add(a,b) > a += 1 > b += 2 > > print

Re: Looping [was Re: Python and the need for speed]

On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote: > Technically, adding this one feature to Python /is/ trivial, for example, > allowing while: as a synonym for while True:, but preferably using a new > keyword such as loop. Nothing else needs to be touched. And it could have > been

Re: Looping [was Re: Python and the need for speed]

On 16/04/2017 13:22, Rustom Mody wrote: On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote: On 16/04/2017 03:51, Steve D'Aprano wrote: On Sat, 15 Apr 2017 10:17 pm, bartc wrote: Yes, I'm constantly surprised at this, as such syntax has a very low cost (in my last compiler,

Re: Static typing [was Re: Python and the need for speed]

On Sun, Apr 16, 2017 at 8:55 PM, bartc wrote: > On 16/04/2017 05:27, Steve D'Aprano wrote: >> >> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: >> >>> apparently, the py-devs believe we >>> only deserve type declarations that do nothing to speed up >>> code execution (aka:

Re: Looping [was Re: Python and the need for speed]

On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote: > On 16/04/2017 03:51, Steve D'Aprano wrote: > > On Sat, 15 Apr 2017 10:17 pm, bartc wrote: > > >> Yes, I'm constantly surprised at this, as such syntax has a very low > >> cost (in my last compiler, supporting 'while' for example

Re: Looping [was Re: Python and the need for speed]

On 16/04/2017 03:51, Steve D'Aprano wrote: On Sat, 15 Apr 2017 10:17 pm, bartc wrote: Yes, I'm constantly surprised at this, as such syntax has a very low cost (in my last compiler, supporting 'while' for example only added 30 lines to the project). That's the advantage of writing your own

Re: Looping [was Re: Python and the need for speed]

Steve D'Aprano writes: > I don't remember the language, but I remember seeing one generalisation of > the repeat/do loop that puts the test in the middle, rather than at the > start or end of the loop. If I remember it was something like: > > DO > setup code #

Re: Static typing [was Re: Python and the need for speed]

On 16/04/2017 05:27, Steve D'Aprano wrote: On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: apparently, the py-devs believe we only deserve type declarations that do nothing to speed up code execution (aka: type-hints), instead of type declarations that could actually speed up the code. Go

Re: Static typing [was Re: Python and the need for speed]

On Sun, 16 Apr 2017 09:48:15 +, alister wrote: > On Sun, 16 Apr 2017 14:27:28 +1000, Steve D'Aprano wrote: > >> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: >> >>> apparently, the py-devs believe we only deserve type declarations that >>> do nothing to speed up code execution (aka:

Re: Static typing [was Re: Python and the need for speed]

On Sun, 16 Apr 2017 14:27:28 +1000, Steve D'Aprano wrote: > On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: > >> apparently, the py-devs believe we only deserve type declarations that >> do nothing to speed up code execution (aka: type-hints), instead of >> type declarations that could

Static typing [was Re: Python and the need for speed]

On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: > apparently, the py-devs believe we > only deserve type declarations that do nothing to speed up > code execution (aka: type-hints), instead of type > declarations that could actually speed up the code. Go > figure! > > I'm not a fan of forced

Looping [was Re: Python and the need for speed]

On Sat, 15 Apr 2017 10:17 pm, bartc wrote: > On 15/04/2017 03:35, Rick Johnson wrote: >> On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com >> wrote: > >> At a minimum, every language should offer >> the following four loop-forms (using Python semantics): >> >> while

Re: Python and the need for speed

On Sun, 16 Apr 2017 12:37 am, bartc wrote: > What proportion of Python implementations depend on executing byte-code? My guess is 100%. Pretty much all modern interpreters of any language execute some form of byte-code or another. The bad old days where interpreters repeatedly parsed and

Re: Python and the need for speed

On 04/15/2017 08:37 AM, bartc wrote: > What proportion of Python implementations depend on executing byte-code? Presumably Nuitka does not depend on any byte code at all. Jython uses JVM byte codes. Iron Python uses .net VM bytecodes. While CPython's byte codes do take their form in part

Re: Python and the need for speed

bartc writes: > 'do', in the original Algol 68 syntax, was part of its 'for' > statement, where you could leave out the parts you don't need. The > full syntax is something like: > > for var := a to b by c while d do body od FOR name FROM e1 BY e2 TO e3 WHILE cond DO body

Re: Python and the need for speed

On 15/04/2017 14:27, Marko Rauhamaa wrote: bartc : while 1: body Why not say it like it is: while True: body but it's more psychological; I don't want to use an idiom to denote an endless loop, I want to be able to express it directly! C's:

Re: Python and the need for speed

On Saturday, April 15, 2017 at 7:17:55 AM UTC-5, bartc wrote: > On 15/04/2017 03:35, Rick Johnson wrote: > > On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote: > > > At a minimum, every language should offer > > the following four loop-forms (using Python semantics): > > >

Re: Python and the need for speed

bartc : > Of course, it's possible to overdo it; if you look at Lisp, you'll lose > yourself in the myriad looping options. Funny, in Scheme, the only looping construct I use is named-let. > The former /can/ be easily written as: > > while 1: > body Why not say it

Re: Python and the need for speed

On Sat, 15 Apr 2017 10:23 am, bartc wrote: > On 15/04/2017 00:40, Rick Johnson wrote: >> * `range(10)` will always produce a list of the _same_ 10 >> integers. > > You don't know if 'range' is still a range. If this has been executed > first, then the answer will be 20: > > oldrange=range

Re: Python and the need for speed

On 15/04/2017 03:35, Rick Johnson wrote: On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote: At a minimum, every language should offer the following four loop-forms (using Python semantics): while CONDITION: doSomething() for VALUE in COLLECTION:

Re: Python and the need for speed

On Thursday, April 13, 2017 at 1:32:28 AM UTC-5, Steven D'Aprano wrote: > On Wed, 12 Apr 2017 14:38:52 +0100, Ben Bacarisse wrote: > > Steve D'Aprano writes: > >> On Wed, 12 Apr 2017 03:39 am, Paul Rubin wrote: > > [...] Indeed, and this is a very common phenomenon: > features which "ordinary"

Re: Python and the need for speed

On Thursday, April 13, 2017 at 1:32:29 AM UTC-5, Gregory Ewing wrote: > Jussi Piitulainen wrote: > > Traceback (most recent call last): > > File "/dev/fd/63", line 37, in > > SanityClauseException: code is blatantly sub-optimal > > > > As far as I know, no language does that. Because reasons?

Re: Python and the need for speed

On Wednesday, April 12, 2017 at 8:44:30 AM UTC-5, bart...@gmail.com wrote: > On Wednesday, 12 April 2017 12:56:32 UTC+1, Jussi Piitulainen wrote: > > bartc writes: > > > > > > These are straightforward language enhancements. > > > > FYI, the question is not how to optimize the code but how > > to

Re: Python and the need for speed

On Wednesday, April 12, 2017 at 4:57:10 AM UTC-5, bart...@gmail.com wrote: > On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote: > > On Tue, 11 Apr 2017 21:10:56 -0700, Rick Johnson wrote: > > > > > > high level languages like Python should make it > > > difficult, if not

  1   2   3   >