Re: syntax difference
Do you think that a feature like swap(x,y) literally only works on two simple variables? X and y represent any two lvalue expressions. For example, a[I] and a[I+1]. Python will evaluate each twice. My version sets up two references then exchanges what they point to with one bytecode. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
I think you're getting a programming language mixed up with a bunch of random libraries. If you want to do any actual coding rather than scripting, such as implementing some of that stuff, then this is where those basic language features that are missing from core Python become useful. What do you do in python when a local function variable needs to retain its value? I'm sure it can do it, but I bet it's not as simple as how I do it. Multi-level loop break? Separators in numbers? I think that one is finally in. You can have all your libraries /and/ have fundamental language features at the same time. They are not mutually exclusive. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Features? Important ones? Go back 40 years and see how important they were then. Most of them,nobody had heard of, and would not be meaningful. Now do the same with my list - most are programming features that could be understood and appreciated even then. Finally, imagine going forward 40 years; how many of those acronyms will still be relevant? But anyone still involved in coding algorithms will likely still find some of my features useful. Although the language will long be gone. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Some of that can be done. It may not need specific support. But my intention is to have an ordinary language for everyday coding not one that can only be understood by CS professors. Mine is unusual in that I can drop features I rarely use, which means that everything in it gets good use. Including multi-level breaks. And the core language can stay small (or smallish - it's not Forth). Which I think is where we came in. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
(Sorry no idea how to do quoting on this mobile app I have to use.) Those examples of using network features are merely examples of function calls. This is what I'm talking about with basic language features. Pointers are merely an extra level of indirection; they can be made to fit. A few things might need language help, or help from its runtime. So that if I wanted a pointer to the first byte of this programs image on windows, I'd have to do: P := makeref(0x40', byte) Which I then access as P^. The stuff you're talking about, imo, is at a completely different level. Someone could take core Python and repackage it with a completely different set of libraries. What happened to the network stuff? -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Yeah, people keep bringing that up when they run out of arguments. So, every programmer must always use the most advanced, most esoteric features possible at every opportunity? Coding should only be for the elite? There is a place for various levels of programming language. I'm saying that Python which is always touted as a 'simple' language suitable for beginners, is missing a surprising number of basics. That these are useful is demonstrated by the cumbersome add-ons that need to be used to provide that functionality. Often in over the top ways and often in a bewildering variety of ways in the case of records. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Pointers are perhaps a more technical feature. Switch and case, the latter a more general version of switch, are universal. Repeat n times is universal. While it is trivial to implement with other constructs, it as an annoyance and distraction that is easily fixed. Now you will probably say it is possible to do without loops at all, or without selecting from one of multiple execution paths (by using functional approaches). I suggest that such features just make life a little simpler. (And make writing an efficient interpreter a little bit easier.) -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
It isn't about my language versus Python. It is about the surprising number of simple features that are missing and that people are claiming don't matter, despite the considerable efforts made to provide them via add-ons. But I'm glad you stepped because making these posts via a smartphone AND google groups is a rather painful experience. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
If you're genuinely interested in how pointers might work I'll try and write that up when I get back to a real machine, and will do it in the form of a link. Since people are clearly unhappy with discussing features that ought to be in Python in a Python forum. -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
The actual interpreter code is irrelevant. Switch would be a feature of the language being interpreted, not of the interpreter. If the task is to match an expression X against a variety of values, then expressing that as a switch means the interpreter /could/ use a jump table (of labels within the byte code), rather than execute a chain of X==Y tests within byte code. So, evaluate X once then it could be a single byte code op. At least, it will know that exactly the same X value is being tested. So you evaluate it once then keep it on the stack. Think of Switch as another kind if hint. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
You're right. While pointers can be made to fit, it would be an awkward fit into Python and could introduce overheads even when not used. My use of them is frequently when straddling boundaries between languages (a pointer in one environment points to the data of another), or when working just outside the language's object system, or using pointers to raw machine types that are not reference counted. This would not be disciplined enough for Python. So forget I mentioned them even though they could open up interesting possibilities such as reference parameters. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: syntax difference
Alister: == which can be implemented in python by putting function calls as members of a list or dictionary switch=[case1,case2,case3] switch[a]() == This is the approach you might use when you don't have a proper switch. It could be done in C that way. Problems: the code for the different cases is not localised. You have to think up function names. The cases must be listed in that order. If the first case is not zero, you have to deal with that. Gaps in the sequence are problematical. You need a way of detecting the default case. There is no association between case number and its entry. The case numbers may be named values, so won't know what order they need to be in. Using a dict will solve some of that, but its not clear what overheads there are in setting up the dict. A proper switch also allows lists, ranges and scalars, or any mix, for each case block. It's not clear how a dict can be used for that, without adding another layer of processing which defeats part of the purpose in having switch. Above all, you lose the clarity of a proper switch construct. Alister: == (although i personally would still like to see a switch if anyone can come up with a suitable syntax that does not break the rest of the python philosophy wtr indentation.) == The syntax is a minor detail. The biggest problem with adding an int-based switch to Python that uses a jump-table is that that requires the case values to be known at compile-time. Usually they won't be. I came up with a way around this which used tentative byte code which is fixed up the first time it is executed. But that is rather hairy, and it means case values are fixed: if A is a case value of 10, then if later on it is 20, it will be treated as 10 still. For such reasons it is unlikely to make it into Python in that form. However a switch statement can still be useful for its expressiveness, and implemented as sequential tests. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
What a friendly, welcoming and open-minded group this is! It costs me some genuine effort to make what I believe are relevant and interesting technical posts, and people are discussing not just how to avoid seeing them, but how to screen anyone who wants to reply. Yes my posts are more 'meta' than some would like but that is fitting for such a language. I in the meantime have to wade through reams of Case Solution and Test Bank posts. Guys, get a proper moderated Usenet group then I won't bother with it at all. -- https://mail.python.org/mailman/listinfo/python-list
Re: Feeding the trolls
Steven D'Aprano wrote: == If you were more interested in appreciating Python for what it is, instead of turning everything into a pissing contest where your personal, private language does it better, your experience might be different. And who knows, you might even learn a thing or two. There's a reason why the Python/Ruby/Lua/Javascript style of languages exists. == You're reading too much in my highlighting a number of features from a much smaller language that I believe could be of benefit. Naturally I wouldn't bring up less useful or inferior features. Nor would I bring up the one or two features of Python I've copied. Nor the ones I haven't got round to copying. Nor the ones I can't yet use because they belong in the next category of language. -- Bart -- https://mail.python.org/mailman/listinfo/python-list
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 opinions matter to us? What's using Python got to do with it? If I needed to write Python as a job, then I'd just get on with it. I probably wouldn't have time to post on here! I don't so can discuss it from a different perspective. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
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 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
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 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 opinions matter to us? > > > > What's using Python got to do with it? If I needed to write Python as a > > job, then I'd just get on with it. I probably wouldn't have time to post on > > here! > > > > I don't so can discuss it from a different perspective. > > I should get into Parliament and start passing laws about cars. I'd > have a valuable perspective on it, since I never drive. Huh? That's exactly what happens! The UK Health Secretary doesn't need to be a doctor; the Chancellor doesn't need an economics degree, etc. 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 might well not get from someone who drives that model for a living. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
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 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 it was tedious and annoying, > because one tiny change meant minutes of compilation. This wasn't my experience. I used my own tools and designed them to always be quick enough in use that compilation speed was never really an issue. Not even on 8-bit machines. I was also happily running my interpreters within 640KB (less than that too depending on customers' machines). So that 128MB limit, or *two hundred* times as much memory, was a hardly a limitation! -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
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 might well not get from someone who drives that model for a > > living. > > > > So've I, but I don't try to tell the Scheme folks that they need to > change the language. You can have an opinion - but it doesn't make it > worth anything. OK. But I both drive, and build my own cars! 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. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
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 merit, that's fine. > > If you are the only one who has ever seen or used these fast bytecode > interpreters, then they might as well not exist, in which case, no, your > opinions have no merit. > > 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 self-promotion, your code wouldn't survive more than six seconds of > peer review. Sure. I can't pretend the implementations are wonderful. But I think the ideas are good and they would make fine little languages when seriously implementated. Not that it bothers me because I've sold $millions of software implemented 100% in these 'toy' languages (and versions from 20+ years ago too). (If you want to try something out, go to: https://github.com/bartg/langs Download the interpreter pcc32.exe (a Windows binary, but I remember it seemed to work under 'wine' in Linux). And test program jpeg.bc (a binary bytecode file). Run as pcc32 jpeg file.jpg (or as wine pcc32 jpeg file.jpg). If it works, the image will be displayed. The sourcecode for jpeg.bc (its main module) is in jpeg.q. (jpeg.m is a separate static language version.) I don't have the Python version to hand, but that has been posted in the past (and which you have already commented on!). There is also qq.bc, a bytecode compiler. Run as pcc32 qq filename.q, but I haven't provided libraries so only simple programs can be compiled. (Note that pcc32.exe is not accelerated; that version is 2-3 times faster on this test.) I'm working at the moment on a version that works like Python, directly on source code rather than precompiled bytecode. But it needs to be fast enough so I'm aiming for a 1M lines per second compilation speed; I've managed 0.8-0.9Mpls so far on real applications.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
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 languages started as streamlined tools that I needed for my job. Commercial products at the time were poor Chris pointed out (and also expensive). -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Slices time complexity
On Thursday, 21 May 2015 18:16:33 UTC+1, Steven D'Aprano wrote: > On Thu, 21 May 2015 11:34 pm, bartc wrote: > > On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano wrote: > > Using what is really pass-by-reference for everything is fine, > > I'm really sure it isn't fine. You could use pass-by-reference for > everything, but if you do, you will surprise a lot of people: Yes, I using the term informally (as in, 'reference count'). I meant how CPython appears to pass data around (as Py_Object* types). > > If small integers need to be heap-allocated and managed, then it might > > need a few more. (And then Python will auto-range these to arbitrary > > precision as needed, another difference.) > > Are you talking about Python or your custom language? My language, and the problems there might be in adopting the CPython style of passing pointers around. (Another problem I've just realised is that everything in my language is mutable: I can even change the the bits of a small integer in-place. That will be interesting to solve.) (I came into this trying to investigate why CPython was so slow, I may end up wondering how it manages to be as fast as it is!) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
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
> > impossible, to write sub-
> > optimal code (at least in the blatantly obvious cases).
>
> Here's another example:
>
> answer = 0
> for i in range(10):
> answer += 1
>
> instead of
>
> answer = 10
>
> So... how exactly does the compiler prohibit stupid code?
Actually, an optimising C compiler (not one of mine!) probably could reduce
that to answer=10. And eliminate even that if 'answer' was never used.
But that's not really the issue here. Assume that such a loop /is/ doing
something more useful. The problems with Python (last time I looked anyway)
were these:
(1) If answer was a global variable, then it needs a symbol table lookup to
find out what it is. That would not happen in a static language, or a less
dynamic one, as you already have the address.
And this lookup happens for every loop iteration.
(2) There is also 'range', which could have been redefined to mean something
else, so /that/ needs a lookup. The byte-code compiler can't just assume this
loop is to be executed 10 times.
(3) This was fixed long ago but at one time, even when 'range' had been
established to be a range, it involved constructing a list of items (10 here,
but it could be a million), and then iterating over the list.
This might seem crazy, but it might have been exceptable for a script language
at one time. Not for a general purpose one however.
(4) Python's integer types being immutable, the += operation means evaluating
the result, then creating a new integer object and binding 'a' to that new
value. (Correct me if I'm wrong.)
These are all things the language could point a finger at before blaming the
user for writing inefficient code.
The problem is also the language encouraging people to use high-level but
inefficient methods, as the emphasis is on productivity and readability**
rather than performance. In fact most users probably have no idea on what is
efficient and what isn't.
If I wanted to work with the code for character 'A' (ie. the integer 65), in
another language it might represent it as 'A' which is mapped to 65. In Python,
'A' is a string. To get the integer code, I have to use ord('A'). To do that,
it has to look up 'ord', than execute a function call... In the meantime the
more static language has long since finished whatever it was going to do with
that code.
(** Although I find code full of class definitions, one-liners, decorators and
all the other esoterics, incomprehensive. I'm sure I'm not the only one, so
perhaps readability isn't too much of a priority either.)
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 10:57:10 UTC+1, bart...@gmail.com wrote: > On Wednesday, 12 April 2017 07:48:57 UTC+1, Steven D'Aprano wrote: > > for i in range(10): > > answer += 1 > > So... how exactly does the compiler prohibit stupid code? > And this lookup happens for every loop iteration. I've just looked at byte-code for that loop (using an on-line Python as I don't have it on this machine). I counted 7 byte-codes that need to be executed per iteration, plus five to set up the loop, one of which needs to call a function. My language does the same loop with only 4 byte-codes. Loop setup needs 2 (to store '10' into the loop counter). It also has the option of using a loop with no control variable (as it's not used here). Still four byte-codes, but the looping byte-code is a bit faster. Plus there is the option of using ++answer instead of answer += 1. Now there are only two byte-codes! (NB don't try ++ in Python.) These are straightforward language enhancements. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
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 prevent the > programmer from writing stupid code in the first place. Someone > suggested that a language should do that. The 'stupid code' thing is a red herring. I assume the code people write is there for a reason. But the language can also play a part in not allowing certain things to be expressed naturally. So the for-loop in the example has to have a control-variable even if it's not referenced. There is no 'case' or 'switch' statement to test one expression against multiple possibilities; usually the suggestion is to use a Dict, more of a heavyweight feature of unknown efficiency. You can't take a numeric constant and give it a name, without turning it into a global variable which now needs a lookup and which can't be folded with other constants. It seems Python completely disregards the question of efficiency, leaving that minor detail to implementations. But they can only work with what the language provides. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 16:50:01 UTC+1, Jussi Piitulainen wrote: > bart4...@gmail.com writes: > > > 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 prevent > >> the programmer from writing stupid code in the first place. Someone > >> suggested that a language should do that. > > > > The 'stupid code' thing is a red herring. I assume the code people > > write is there for a reason. > > So you walked in to a conversation about something that does not > interest you and simply started talking about your own thing. > > Because of course you did. > > I get confused when you do that. Huh? The subject is making Python faster. It's generally agreed that being very dynamic makes that harder, everything else being equal. I don't agree that stopping people writing silly code is that helpful. It might be in the itself silly example of 'for i in range(10): x+=1', but usually there will be a good reason for such a loop. If you want to argue that bad choices of algorithm and bad code are a factor in performance, then there's that too. But that applies equally to every language. You can choose the best algorithm and perfectly correct code, and Python will still most likely execute it more slowely than a less dynamic language. If by some chance Python is faster, then it will probably be because it's offloading the real work to some library, not written in Python. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Wednesday, 12 April 2017 16:04:53 UTC+1, Brecht Machiels wrote: > On 2017-04-12 14:46:45 +, Michael Torrie said: > It would be great if you could run the benchmark I mention in my first > link and share the results. Highly appreciated! Were you ever able to isolate what it was that's taking up most of the time? Either in general or in the bit that pypy has trouble with. Or is execution time spread too widely? (I looked at your project but it's too large, and didn't get much further with the github benchmark, which requires me to subscribe, but the .sh file extensions don't seem too promising to someone on Windows.) Your program seems to be to do with typesetting. Is it possible to at least least quantity the work that is being done in terms of total bytes (and total files) of input, and bytes of output? That might enable comparisons with other systems executing similar tasks, to see if the Python version is taking unreasonably long. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and the need for speed
On Thursday, 13 April 2017 00:09:35 UTC+1, Gregory Ewing wrote: > bart4...@gmail.com wrote: > > > But the language can also play a part in not allowing certain things to be > > expressed naturally. So the for-loop in the example has to have a > > control-variable even if it's not referenced. > > If the compiler can recognise when code is "stupid", it's > probably capable of doing something more intelligent than > just rejecting it outright. > > E.g. it could notice that a loop variable wasn't used > anywhere in the function and optimise it out. And it could > recognise x += 1 and emit an ADD_ONE bytecode for it. > Etc. Maybe. (Although I think Python would have difficulty in turning x+=1 into a single opcode, if using normal object references and a shared object model.) But I wouldn't be happy about a language deciding my code is 'stupid'. I might for example have an N-times loop containing x+=1 because I want to know how long it takes to execute x+=1 N times. (This is a common problem with benchmarking code actually, as you can end up measuring how long it takes /not/ to do something instead of doing it!) Anyway that loop example (I think it was Steve's) was a simple illustration. It will usually be harder to figure out if a bit of code is rational. Even with x+=1, isn't it possible to override the + or += operation with user code? Code which change the handling method at each iteration. This is dynamism making a rod for its own back. 99.99...% of the time that won't happen, but... -- bartc -- https://mail.python.org/mailman/listinfo/python-list
