Python and Flaming Thunder
I've read that one of the design goals of Python was to create an easy- to-use English-like language. That's also one of the design goals of Flaming Thunder at http://www.flamingthunder.com/ , which has proven easy enough for even elementary school students, even though it is designed for scientists, mathematicians and engineers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is using range() in for loops really Pythonic?
On May 10, 8:19 pm, John Salerno <[EMAIL PROTECTED]> wrote: > It seems somewhat > artificial to use the for loop to do something a certain number of > times, like above. I agree; it's a common flaw with lots of languages, not just Python. I'd be inclined to use something like: FOR 8 TIMES DO . or: REPEAT FOR 8 TIMES. as a compromise between readability and machine-parsability. If anyone has other suggestions, please post them here and I'll implement one of them next weekend in Flaming Thunder. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 12, 6:32 pm, [EMAIL PROTECTED] wrote: > Can you render some furniture for me... to try to see some human > posture to lowest energy levels. Not yet; Flaming Thunder doesn't have built-in graphics yet. But we're incorporating the graphics from www.dpgraph.com , so when that's finished, then yes Flaming Thunder will be able to render furniture and calculate energy levels. If I remember correctly, I think that NASA did some experiments many years ago on human posture and found that laying back (like the astronauts do at takeoff) minimized stress on the human body due to high g-forces. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 12, 6:32 pm, [EMAIL PROTECTED] wrote: > Can you render some furniture for me... to try to see some human > posture to lowest energy levels. I couldn't find any furniture created using DPGraph, but the math art gallery at http://www.dpgraph.com/math-art.html has a sailboat, an F15, Tux (the Linux penguin), a lampshade, and lots of other things that will soon be doable in Flaming Thunder. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 12, 7:12 pm, [EMAIL PROTECTED] wrote: > Mine's been always messing up the color wheel. Messing up in what way? Are you using the colors to visualize something? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 12, 7:20 pm, [EMAIL PROTECTED] wrote: > Yes, I am trying to visualize something. If it is related to making furniture comfortable for humans, have you considered painting the furniture with thermochromic paint ( http://en.wikipedia.org/wiki/Thermochromism )? It changes color in response to temperature, which in part is determined by how hard a body is pressed against it because close contact tends to trap heat. An evenly distributed color might indicated evenly distributed pressure. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is using range() in for loops really Pythonic?
> REXX's loop construct subsumes all the common uses... And worse, it > appears that a repetition and a condition can be part of the single > statement. Thank you for pointing out the REXX examples. I am a Kedit user, but had forgotten about the REXX do-loops. I'll keep them in mind when I add an easy way to "do this n times" to Flaming Thunder this weekend. On May 11, 8:53 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Mon, 12 May 2008 00:43:08 GMT, Jonathsn Cronin <[EMAIL PROTECTED]> > declaimed the following in comp.lang.python: > > > I agree in principle; the first is iteration and the second is repetition. > > In Python, the common idiom for a fixed number of repetitions is iterating > > over a number range. This is true in most languages I am familiar with, > > probably because fixed repetition, where you don't care about the "index" > > value, is rarely used. > > > The only language I've used that does have fixed repetition is an (old) > > dialect of lisp, and I'm not sure it even made it into Common Lisp. > > Smalltalk and Ruby do have fixed repetition. > > REXX's loop construct subsumes all the common uses... And worse, it > appears that a repetition and a condition can be part of the single > statement. > > DO FOREVER > ... > END > > DO repeatcount > ... > END > > DO loopvar=first TO last BY step FOR reptcount > ... > END > > (where "TO last", "BY step", "FOR reptcount" are all optional clauses!) > > DO WHILE conditional > ... > END > > DO UNTIL conditional > ... > END > > Mixing modes > > DO loopvar=first BY step UNTIL conditional > ... > END > > Hmmm, looks like it's been extended for container objects (those that > support MAKEARRAY): > > DO item OVER container > ... > END > -- > Wulfraed Dennis Lee Bieber KD6MOG > [EMAIL PROTECTED] [EMAIL PROTECTED] > HTTP://wlfraed.home.netcom.com/ > (Bestiaria Support Staff: [EMAIL PROTECTED]) > HTTP://www.bestiaria.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 12, 11:52 pm, [EMAIL PROTECTED] wrote: > I do hold an argument that one can make too much money for one's own > good quality of life. As do I; I think there is an optimal amount. Too little, and you waste time gathering food. Too much, and you waste time gathering money. > Am I trying to visualize thermal (and ergo > possibly chemical too) gradients (thermovoltaic)? Yes in part. Some of those DPGraph (and soon, Flaming Thunder) may be able to help with. > I'm pretty generally interested, but where can print layout take you? Not far, especially with books disappearing. Our library says that these days, only 25% of their checkouts are books; the other 75% are DVDs, CDs, etc. > Microsales? And getting microer every day. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> Don't let yourself be irritated by castironpi I'm not the sort to get irritated by anyone. There is value in all interaction. Flaming Thunder is itself the averaging of interactions with many computer languages and conversations with many people, so as to create a language that allows people to tell a computer what they want it to do, without having to know very much about how the computer does it. On May 13, 3:18 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > Dave Parker wrote: > > On May 12, 7:20 pm, [EMAIL PROTECTED] wrote: > >>Yes, I am trying to visualize something. > > > If it is related to making furniture comfortable for humans, have you > > considered painting the furniture with thermochromic paint ( > >http://en.wikipedia.org/wiki/Thermochromism)? It changes color in > > response to temperature, which in part is determined by how hard a > > body is pressed against it because close contact tends to trap heat. > > An evenly distributed color might indicated evenly distributed > > pressure. > > Don't let yourself be irritated by castironpi - he's the virtual equivalent > of a mumbling mad man in this group. Ignorance serves best as remedy - and > getting a filter to work, as I did (so I only see his postings being > quoted... a huge relief!) > > Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 13, 7:44 am, [EMAIL PROTECTED] wrote: > I am not convinced that the colorspace occupies three dimensions necessarily. Apparently there are some people -- called tetrachromats -- who can see color in four dimensions. They have extra sets of cones in their retinas containing a different photopigment. So, the dimensions of color appear to be an artifact of our visual systems, and not inherent in the colors themselves which are linear (one-dimensional) in frequency. http://en.wikipedia.org/wiki/Tetrachromacy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> The "Flaming Thunder" looks promising, but without being free > software, it's unlikely it will create a large developer community, > specially considering both free general purpose and scientific > programming languages. Perhaps. Flaming Thunder is only $19.95 per year for an individual (and even less per individual for site licenses), which is less than the cost of just one book on Python. I think that many people will find that Flaming Thunder is easier to use and understand than Python -- so for many people the amount of time they save will be worth more than the cost of Flaming Thunder (unless, of course, their time is worth $0). Also, several users have rewritten their Python programs in Flaming Thunder, and found that Flaming Thunder was 5 to 10 times faster (Flaming Thunder compiles to native executables). So again, since many people value their time at more than $0, I think that many people will find that Flaming Thunder is worth $19.95 per year. Plus, me getting paid to work on Flaming Thunder is far more motivating than me not getting paid to work on Python. This weekend, Python users will still be debating how to fix awkwardnesses in the languages (such as FOR loops where you're just counting the loops and not referencing the loop variable) -- but Flaming Thunder users will be getting work done using the REPEAT n TIMES constructs that I'll be implementing. Python has been around about 15 years, yet still has those awkwardnesses. Flaming Thunder has been out less than 6 months and those awkwardnesses are already getting fixed. The difference: I can't afford to ignore users. But the future is one of the hardest things to predict, so we'll see. On May 13, 8:34 am, hdante <[EMAIL PROTECTED]> wrote: > On May 13, 10:58 am, Paul McGuire <[EMAIL PROTECTED]> wrote: > > > > > > > On May 13, 8:32 am, Dave Parker <[EMAIL PROTECTED]> wrote: > > > > > Don't let yourself be irritated by castironpi > > > > I'm not the sort to get irritated by anyone. There is value in all > > > interaction. > > > Not this interaction, I'm afraid. What irritates *me* about > > castironpi is that he uses a chatterbot to clutter up the threads > > here. If you go back to his postings from a year ago (and selected > > ones since), his comments are coherent and sensible. These rambling > > stream-of-consciousness rants about t.v.'s and coffee are (I guess) > > his idea of a joke. But they are certainly not worth your time in > > trying to respond to them. > > > -- Paul > > I don't think castironpi so annoying that I should filter its > messages. It would be enough if he were better tuned. He is much > smarter than the emacs shrink, for example. :-P > > The "Flaming Thunder" looks promising, but without being free > software, it's unlikely it will create a large developer community, > specially considering both free general purpose and scientific > programming languages.- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> 5-10 times faster for what kind of code? Mostly numerical analysis and CGI scripting. All of Flaming Thunder's library code is in assembly language, and Flaming Thunder creates statically-linked pure syscall CGI scripts. > I don't see anything that resembles OO features of python, ... True. But in Python, you don't see statically-linked pure-syscall CGI scripts being cross-compiled under Windows for ftp'ing up to a Linux server. And you don't see the speed of pure assembly language libraries. And I'll be willing to bet that Flaming Thunder will have OO features similar to Python before Python has the features that Flaming Thunder already does. For many people, being 5 to 10 times faster at numerical analysis and CGI scripting is reason enough to pay $19 per year. But maybe for other people, having slow, inefficient programs and websites is acceptable. > And what is really expensive is brain-cycles, not cpu-cycles. Depends on whether you're the programmer, or the customer. I've found that customers prefer products that are 5 to 10 times faster, instead of products that were easy for the developer. And I disagree that Flaming Thunder requires more brain-cycles. Because it's based on leveraging existing English and math fluency (which was one of the original goals of Python, was it not?), I think that Flaming Thunder requires fewer brain-cycles because fewer brains cells have to be devoted to memorizing language peculiarities. > Let alone it is > very much a question of view-point if two different looping constructs or > keywords are more awkward than one general looping-concept with only one > keyword. It's a matter of taste. Perhaps. But if elementary school students can easily understand why one programming language gives the answer 100 (Flaming Thunder): Write 10^2. but can't understand why another programming language gives the answer 8 (Python): Print 10^2 then I think the comparison moves beyond a matter of taste into the realm of measurable ease-of-use. On May 13, 9:50 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > Also, several users have rewritten their Python programs in Flaming > > Thunder, and found that Flaming Thunder was 5 to 10 times faster > > (Flaming Thunder compiles to native executables). So again, since > > many people value their time at more than $0, I think that many people > > will find that Flaming Thunder is worth $19.95 per year. > > 5-10 times faster for what kind of code? I don't see anything that resembles > OO features of python, let alone more advanced concepts like > meta-programming, higher-order functions and such. Which save tremendous > amounts of time coding. If FT grows these and *still* is 5-10 times faster, > I'll salut you. > > And what is really expensive is brain-cycles, not cpu-cycles. Which above > described features save. > > > Plus, me getting paid to work on Flaming Thunder is far more > > motivating than me not getting paid to work on Python. This weekend, > > Python users will still be debating how to fix awkwardnesses in the > > languages (such as FOR loops where you're just counting the loops and > > not referencing the loop variable) -- but Flaming Thunder users will > > be getting work done using the REPEAT n TIMES constructs that I'll be > > implementing. > > > Python has been around about 15 years, yet still has those > > awkwardnesses. Flaming Thunder has been out less than 6 months and > > those awkwardnesses are already getting fixed. The difference: I > > can't afford to ignore users. > > Oh *please*! Try getting nearly as feature & library complete as python is > today - and *then* I'll point to all the akwardness of FT. Let alone it is > very much a question of view-point if two different looping constructs or > keywords are more awkward than one general looping-concept with only one > keyword. It's a matter of taste. > > Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> ... there's something that feels very unnatural about writing English as code. I think it is ironic that you think Flaming Thunder is unnatural because it is more English-like, when being English-like was one of Python's goals: "Python was designed to be a highly readable language. It aims toward an uncluttered visual layout, using English keywords frequently where other languages use punctuation." http://en.wikipedia.org/wiki/Python_(programming_language)#Syntax_and_semantics > Just using your "Set ... to" idiom, rather than a > regular = assignment, makes things much more wordy, without improving > readability. I think it does improve readability, especially for people who are not very fluent mathematically. Also, in Python how do you assign a symbolic equation to a variable? Like this? QuadraticEquation = a*x^2 + b*x + c = 0 Set statements avoid the confusion of multiple equal signs when manipulating symbolic equations: Set QuadraticEquation to a*x^2 + b*x + c = 0. On May 13, 9:50 am, "Dan Upton" <[EMAIL PROTECTED]> wrote: > On Tue, May 13, 2008 at 11:24 AM, Dave Parker > > <[EMAIL PROTECTED]> wrote: > > > The "Flaming Thunder" looks promising, but without being free > > > software, it's unlikely it will create a large developer community, > > > specially considering both free general purpose and scientific > > > programming languages. > > > Perhaps. Flaming Thunder is only $19.95 per year for an individual > > (and even less per individual for site licenses), which is less than > > the cost of just one book on Python. > > Bah, subscription for a programming language? As far as I'm > concerned, that's reason enough not to bother with it. Paying a > one-time fee, or even once per upgrade, for a full-featured IDE and > lots of support tools is painful but at least justifiable, whereas > paying a yearly license just to even be able to try something out when > there are so many free, sufficient options... There was an article > on/in Wired not so long ago about the economics of free, and how > there's a huge difference mentally between free and not-free, even if > the practical difference is "free" and "$0.01." (Also, I assume > hdante meant, at least partly, free as in speech, not free as in > beer.) > > As an aside, I clearly haven't written anything in FT, but looking at > your examples I don't know that I would want to--there's something > that feels very unnatural about writing English as code. It also > somehow seems a bit verbose, while one of the strengths of something > like Python (since that's what you're comparing it to) is rapid > implementation. Just using your "Set ... to" idiom, rather than a > regular = assignment, makes things much more wordy, without improving > readability. Some of your other structures are awkward, for instance > "Something is a function doing" Again, more text with arguably no gain > in readability. > > Just my two cents, anyway. I now return you to the resident madman, > who I see has sent 4 or 5 messages while I was typing this one... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> Just to support this statement: PHP runs an order of magnitude slower than > python. Yet a great deal (if not the majority) of dynamic sites out there > run under PHP. All of these are unhappy customers? The websites owners might not be unhappy, but lots of customers complain about slow websites, so if the market is competitive then eventually the PHP fad will die out. For example, Slashdot recently interviewed a successful website in a competitive market -- online newspapers -- and found that to enhance customer happiness the New York Times uses hand-coded HTML. "He was asked how the Web site looks so consistently nice and polished no matter which browser or resolution is used to access it. His answer begins: 'It's our preference to use a text editor, like HomeSite, TextPad or TextMate, to "hand code" everything, rather than to use a wysiwyg (what you see is what you get) HTML and CSS authoring program, like Dreamweaver. We just find it yields better and faster results.'" http://news.slashdot.org/article.pl?sid=08/04/30/009245&from=rss "Faster" wins in a competitive market, so if a programming language can't deliver "faster", it is a fad that will die out. On May 13, 10:40 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > This shows how much you don't know about customers, and their needs. A > > customer gives a s**t about 5-10 times faster sites. They care if it is > > *fast enough*, but beyond that they don't bother. But what *always* > > bothers them is development time & flexibility. Because that directly > > affects the price they pay. > > Just to support this statement: PHP runs an order of magnitude slower than > python. Yet a great deal (if not the majority) of dynamic sites out there > run under PHP. All of these are unhappy customers? > > Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> Notice that I said "free software", not "*** FREE *** software > 1!" (that is, free as in freedom, not free as in beer). Read again my > answer, considering this. I misread your meaning. In a sense, Flaming Thunder is even more free than "free software". Flaming Thunder doesn't place any restrictions on how you use your source code or the executables you create. There is no GNU license that you need to worry about. On May 13, 11:06 am, hdante <[EMAIL PROTECTED]> wrote: > On May 13, 12:24 pm, Dave Parker <[EMAIL PROTECTED]> > wrote: > > > > > > > > The "Flaming Thunder" looks promising, but without being free > > > software, it's unlikely it will create a large developer community, > > > specially considering both free general purpose and scientific > > > programming languages. > > > Perhaps. Flaming Thunder is only $19.95 per year for an individual > > (and even less per individual for site licenses), which is less than > > the cost of just one book on Python. > > > I think that many people will find that Flaming Thunder is easier to > > use and understand than Python -- so for many people the amount of > > time they save will be worth more than the cost of Flaming Thunder > > (unless, of course, their time is worth $0). > > > Also, several users have rewritten their Python programs in Flaming > > Thunder, and found that Flaming Thunder was 5 to 10 times faster > > (Flaming Thunder compiles to native executables). So again, since > > many people value their time at more than $0, I think that many people > > will find that Flaming Thunder is worth $19.95 per year. > > > Plus, me getting paid to work on Flaming Thunder is far more > > motivating than me not getting paid to work on Python. This weekend, > > Python users will still be debating how to fix awkwardnesses in the > > languages (such as FOR loops where you're just counting the loops and > > not referencing the loop variable) -- but Flaming Thunder users will > > be getting work done using the REPEAT n TIMES constructs that I'll be > > implementing. > > > Python has been around about 15 years, yet still has those > > awkwardnesses. Flaming Thunder has been out less than 6 months and > > those awkwardnesses are already getting fixed. The difference: I > > can't afford to ignore users. > > > But the future is one of the hardest things to predict, so we'll see. > > > On May 13, 8:34 am, hdante <[EMAIL PROTECTED]> wrote: > > > > On May 13, 10:58 am, Paul McGuire <[EMAIL PROTECTED]> wrote: > > > > > On May 13, 8:32 am, Dave Parker <[EMAIL PROTECTED]> wrote: > > > > > > > Don't let yourself be irritated by castironpi > > > > > > I'm not the sort to get irritated by anyone. There is value in all > > > > > interaction. > > > > > Not this interaction, I'm afraid. What irritates *me* about > > > > castironpi is that he uses a chatterbot to clutter up the threads > > > > here. If you go back to his postings from a year ago (and selected > > > > ones since), his comments are coherent and sensible. These rambling > > > > stream-of-consciousness rants about t.v.'s and coffee are (I guess) > > > > his idea of a joke. But they are certainly not worth your time in > > > > trying to respond to them. > > > > > -- Paul > > > > I don't think castironpi so annoying that I should filter its > > > messages. It would be enough if he were better tuned. He is much > > > smarter than the emacs shrink, for example. :-P > > > > The "Flaming Thunder" looks promising, but without being free > > > software, it's unlikely it will create a large developer community, > > > specially considering both free general purpose and scientific > > > programming languages.- Hide quoted text - > > > > - Show quoted text - > > Notice that I said "free software", not "*** FREE *** software > 1!" (that is, free as in freedom, not free as in beer). Read again my > answer, considering this.- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> Who has conducted the research that supports that statement? And since when > is ^ the better operator for "to the power of" that **? Because latex uses > it? I need to see the elementary school students who use that... All of the calculators and textbooks that elementary school students use, use "^" for powers. Just like Flaming Thunder does. I haven't seen "**" for powers since FORTRAN. On May 13, 10:38 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > True. But in Python, you don't see statically-linked pure-syscall CGI > > scripts being cross-compiled under Windows for ftp'ing up to a Linux > > server. And you don't see the speed of pure assembly language > > libraries. And I'll be willing to bet that Flaming Thunder will have > > OO features similar to Python before Python has the features that > > Flaming Thunder already does. > > Your bets don't count anything here. These things don't exist, so don't brag > on them being superior. > > > For many people, being 5 to 10 times faster at numerical analysis and > > CGI scripting is reason enough to pay $19 per year. But maybe for > > other people, having slow, inefficient programs and websites is > > acceptable. > > Quite a revealing statement I'd say. And unless you don't show any > real-world site running on FT that needs things like sessions, cookies, > database-connectivity, unicode and a ton more of stuff FT doesn't support > out-of-the-box or through 3rd-party-libs, I wouldn't mention "the people" > as well. So far, *all* that you've been showing on your site regarding CGI > are toy-scripts. Nothing more. > > >> And what is really expensive is brain-cycles, not cpu-cycles. > > > Depends on whether you're the programmer, or the customer. I've found > > that customers prefer products that are 5 to 10 times faster, instead > > of products that were easy for the developer. > > This shows how much you don't know about customers, and their needs. A > customer gives a s**t about 5-10 times faster sites. They care if it is > *fast enough*, but beyond that they don't bother. But what *always* bothers > them is development time & flexibility. Because that directly affects the > price they pay. > > And if a average man-day costs $600 (which is not expensive), and the > project is of average size of a couple of man-months - well, you care about > mathematics, do the math yourself what that means that FT lacks anything > but a simple CGI-interface. > > > And I disagree that Flaming Thunder requires more brain-cycles. > > Because it's based on leveraging existing English and math fluency > > (which was one of the original goals of Python, was it not?), I think > > that Flaming Thunder requires fewer brain-cycles because fewer brains > > cells have to be devoted to memorizing language peculiarities. > > It does require more, because it lacks all the libs and 3rdparty-libs. And > because it lacks features such as OO and other stuff, it will be harder to > write these as well as use them. > > Show me how to beat a quickstarted TurboGears/Django webproject. *Then* you > can talk business here. > > > Perhaps. But if elementary school students can easily understand why > > one programming language gives the answer 100 (Flaming Thunder): > > > Write 10^2. > > > but can't understand why another programming language gives the answer > > 8 (Python): > > > Print 10^2 > > > then I think the comparison moves beyond a matter of taste into the > > realm of measurable ease-of-use. > > Who has conducted the research that supports that statement? And since when > is ^ the better operator for "to the power of" that **? Because latex uses > it? I need to see the elementary school students who use that... > > Even *if* that would be true, how does a perceived advantage in one field FT > was explicitly created for show that it is the generally better one and > understandable one for more diverse applications? > > Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> You sound like a commercial. Get Flaming Thunder for only $19.95! It slices, it dices! > And while programs and libraries written in assembly may be twice as fast > as programs and libraries written in C, ... It's a myth that they're only twice as fast. An experienced assembly language programmer can usually get out at least a factor of 5 by using tricks such as cache-coherence, carry flag tricks, stack manipulations, etc. > ... they're real hell to maintain. That's also a myth. For example, if C is easy to maintain, why is Flaming Thunder the only single-asset 8-by-8 shotgun cross compiler in the world? There should be lots of single-asset 8-by-8 shotgun cross compilers written in C, if C is easier to maintain. Here's one of the tricks I use: I wrote an assembly language preprocessor that takes 1 assembly language source file and generates the library code for the 8 different target platforms. That's much easier than maintaining quirky C code across 8 different platforms -- which is why GCC's support for cross-compilation is often so broken. On May 13, 10:57 am, "Andrii V. Mishkovskyi" <[EMAIL PROTECTED]> wrote: > You sound like a commercial. Is this your way of attracting costumers of FT? > > 2008/5/13 Dave Parker <[EMAIL PROTECTED]>: > > > > 5-10 times faster for what kind of code? > > > Mostly numerical analysis and CGI scripting. All of Flaming Thunder's > > library code is in assembly language, and Flaming Thunder creates > > statically-linked pure syscall CGI scripts. > > > > I don't see anything that resembles OO features of python, ... > > > True. But in Python, you don't see statically-linked pure-syscall CGI > > scripts being cross-compiled under Windows for ftp'ing up to a Linux > > server. And you don't see the speed of pure assembly language > > libraries. > > I see your assembly language libraries and raise you C language libraries. :) > Python libraries have the speed of pure C language libraries. And > while programs and libraries written in assembly may be twice as fast > as programs and libraries written in C, they're real hell to maintain. > But that doesn't stop you from telling us, that: > > > And I'll be willing to bet that Flaming Thunder will have > > OO features similar to Python before Python has the features that > > Flaming Thunder already does. > > Well, we'll see. But, IMHO, this is highly unlikely. > > > For many people, being 5 to 10 times faster at numerical analysis and > > CGI scripting is reason enough to pay $19 per year. But maybe for > > other people, having slow, inefficient programs and websites is > > acceptable. > > Yeah, right, Python is so slow. :) Show us some sites and programs > that were written in FT. > > > > > > And what is really expensive is brain-cycles, not cpu-cycles. > > > Depends on whether you're the programmer, or the customer. I've found > > that customers prefer products that are 5 to 10 times faster, instead > > of products that were easy for the developer. > > If I'm customer, than why should I care about FT? > If I'm a programmer, I'd better care about brain-cycles. > > > > > And I disagree that Flaming Thunder requires more brain-cycles. > > Because it's based on leveraging existing English and math fluency > > (which was one of the original goals of Python, was it not?), I think > > that Flaming Thunder requires fewer brain-cycles because fewer brains > > cells have to be devoted to memorizing language peculiarities. > > Not everybody has grown in English-speaking community, you know. And > knowing math quite good, I prefer writing "x = y" instead of "Set x to > y". > > > > > > > > > > Let alone it is > > > very much a question of view-point if two different looping constructs or > > > keywords are more awkward than one general looping-concept with only one > > > keyword. It's a matter of taste. > > > Perhaps. But if elementary school students can easily understand why > > one programming language gives the answer 100 (Flaming Thunder): > > > Write 10^2. > > > but can't understand why another programming language gives the answer > > 8 (Python): > > > Print 10^2 > > > then I think the comparison moves beyond a matter of taste into the > > realm of measurable ease-of-use. > > '^' is a bitwise XOR. Python uses "x**y" for raising x to power of y. > What's your point here? > > > > > &g
Re: Python and Flaming Thunder
Time for me to get back to work now. Thank you all for your comments, they will help to make Flaming Thunder a better product. I can see that many people would like the ability to link to existing applications and libraries, etc, so I will raise that on my priority list. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is using range() in for loops really Pythonic?
Your point about for-loops was applicable not only to Python, but to many other programming languages. So in response, I've added two new for-loop variations to Flaming Thunder. The two new variations are for-forever-do and for-expression-times-do. For-forever allows you to explicitly create infinite loops, and for- expression-times allows you to do something a specific number of times without having to declare a looping variable if you don't need one. Examples: Write "Fa". For 8 times do write "-la". For forever do ( Write "Do you know the definition of insanity? ". Read response. ). On May 10, 8:19 pm, John Salerno <[EMAIL PROTECTED]> wrote: > I know it's popular and very handy, but I'm curious if there are purists > out there who think that using something like: > > for x in range(10): > #do something 10 times > > isunPythonic. The reason I ask is because the structure of the for loop > seems to be for iterating through a sequence. It seems somewhat > artificial to use the for loop to do something a certain number of > times, like above. > > Anyone out there refuse to use it this way, or is it just impossible to > avoid? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> > I <[EMAIL PROTECTED]> wrote: > > Plus, me getting paid to work on Flaming Thunder is far more > > motivating than me not getting paid to work on Python. > On May 14, 8:30 pm, John Salerno <[EMAIL PROTECTED]> wrote: > That's truly disappointing. I guess I could have stated that better. Flaming Thunder is a labor of love for me. I've programmed in almost every language since FORTRAN and Lisp, and Flaming Thunder is the language I've always wished the others were. For one example, I've always preferred compiled languages because they're faster. So Flaming Thunder is compiled. For another example, I've always preferred languages that are English- like because it's easier to return to your code after several years and still know what you were doing (and it's easier for someone else to maintain your code). For over 5 years I've been working on Flaming Thunder unpaid and on my own, getting the back-end up and running. 8-by-8 shotgun cross compilers written in assembly language, that can fit all of the libraries for both the 32- and 64-bit versions of FreeBSD, Linux, Mac OS X and Windows into a single executable file that's less than 180K, aren't written overnight. So now that I've released it, it's extremely gratifying that people think it's cool enough to actually pay $19 for it. That gives me lots of motivation (and buys enough time) for me to add features to it as fast as possible. To whit: you pointed out the awkwardness in Python of having to declare a for-loop variable when you only wanted to loop a specific number of times and didn't need the variable. Last week, Flaming Thunder had the same awkwardness. If you wanted to loop 8 times: for i from 1 to 8 do you still had to use a variable (in this case, i). This week, I've added two new for-loop variations that fix that awkwardness, and also allow you to explicitly declare an infinite loop without having to rely on idiomatic constructs such as while-true. Examples of the two new variations (for-forever and for-expression-times): Write "Fa". For 8 times do write "-la". For forever do ( Write "Do you know the definition of insanity? ". Read response. ). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 13, 11:42 am, Grant Edwards <[EMAIL PROTECTED]> wrote: > Well, python will definitely never have a name that sounds like > a slang term for happens after you get food poisioning at a > Thai restaurant... :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 14, 7:59 pm, John Salerno <[EMAIL PROTECTED]> wrote: > Would it be valid to say: > > x = "concrete" > > or to say: > > if command (is) set to "quit" > > ?? I like the idea of: If command is set to "quit" ... I've added it to my list of things to think about, and possibly implement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> Personally (and borrowing from Python), I'd prefer something more > like: > > Write "Fa". > Repeat 8 times: > Write "-la". I actually kind of prefer that, too. Or Repeat 8 times write "-la". I'll think about it. Thank you for suggesting it. On May 20, 3:40 pm, MRAB <[EMAIL PROTECTED]> wrote: > On May 20, 4:20 am, Dave Parker <[EMAIL PROTECTED]> wrote: > > > > > > > I <[EMAIL PROTECTED]> wrote: > > > > Plus, me getting paid to work on Flaming Thunder is far more > > > > motivating than me not getting paid to work on Python. > > > On May 14, 8:30 pm, John Salerno <[EMAIL PROTECTED]> wrote: > > > That's truly disappointing. > > > I guess I could have stated that better. Flaming Thunder is a labor > > of love for me. I've programmed in almost every language since > > FORTRAN and Lisp, and Flaming Thunder is the language I've always > > wished the others were. > > > For one example, I've always preferred compiled languages because > > they're faster. So Flaming Thunder is compiled. > > > For another example, I've always preferred languages that are English- > > like because it's easier to return to your code after several years > > and still know what you were doing (and it's easier for someone else > > to maintain your code). > > > For over 5 years I've been working on Flaming Thunder unpaid and on my > > own, getting the back-end up and running. 8-by-8 shotgun cross > > compilers written in assembly language, that can fit all of the > > libraries for both the 32- and 64-bit versions of FreeBSD, Linux, Mac > > OS X and Windows into a single executable file that's less than 180K, > > aren't written overnight. > > > So now that I've released it, it's extremely gratifying that people > > think it's cool enough to actually pay $19 for it. That gives me lots > > of motivation (and buys enough time) for me to add features to it as > > fast as possible. > > > To whit: you pointed out the awkwardness in Python of having to > > declare a for-loop variable when you only wanted to loop a specific > > number of times and didn't need the variable. Last week, Flaming > > Thunder had the same awkwardness. If you wanted to loop 8 times: > > > for i from 1 to 8 do > > > you still had to use a variable (in this case, i). This week, I've > > added two new for-loop variations that fix that awkwardness, and also > > allow you to explicitly declare an infinite loop without having to > > rely on idiomatic constructs such as while-true. Examples of the two > > new variations (for-forever and for-expression-times): > > > Write "Fa". > > For 8 times do write "-la". > > Personally (and borrowing from Python), I'd prefer something more > like: > > Write "Fa". > Repeat 8 times: > Write "-la". > > > For forever do > > ( > > Write "Do you know the definition of insanity? ". > > Read response. > > ). > > Repeat: > Write "Do you know the definition of insanity? ". > Read response.- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> Or just: > > If command is "quit" ... Hmmm. In Flaming Thunder, I'm using "is" (and "is an", "is a", etc) for assigning and checking types. For example, to read data from a file and check for errors: Read data from "input.txt". If data is an error then go to ... Or when assigning a type to an identifier: HarmonicMean is a function(x, y) ... LoopCount is a variable ... By using = only for equality and "is" only for types, the Flaming Thunder compiler can detect when either is being used incorrectly because the syntax for the two is incompatible. That avoids the man- years of wasted debugging time spent on languages that accept statements that are easily confused, yet syntactically valid (e.g. the confusion between = and == in C if-statments, or the confusion between = (equality) and "is" (identity) in Python). On May 20, 3:41 pm, MRAB <[EMAIL PROTECTED]> wrote: > On May 20, 4:33 am, Dave Parker <[EMAIL PROTECTED]> wrote: > > > > > On May 14, 7:59 pm, John Salerno <[EMAIL PROTECTED]> wrote: > > > > Would it be valid to say: > > > > x = "concrete" > > > > or to say: > > > > if command (is) set to "quit" > > > > ?? > > > I like the idea of: > > > If command is set to "quit" ... > > Or just: > > If command is "quit" ... > > > > > I've added it to my list of things to think about, and possibly > > implement.- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 20, 7:05 pm, Collin <[EMAIL PROTECTED]> wrote: > Personally, FT is a bit meh to me. The way you issue your statements I > always think something is wrong, mainly because when I want to define, > say, x, in python I'd go: > > x = "whatever" > > Instantly noting that I defined x. While in Flaming Thunder I'd have to > type: > > Set x to "whatever" > > It just feels wrong. Actually, it felt wrong to me when I first started working on Flaming Thunder because I've been programming for decades and have had all of the programming idioms burned into my brain. But after getting input from children and teachers, etc, it started feeling right. For example, consider the two statements: x = 8 x = 10 The reaction from most math teachers (and kids) was "one of those is wrong because x can't equal 2 different things at the same time". Many computer languages conflate "equality" with "assignment" and then go to even more confusing measures to disambiguate them (such as using == for equality, or := for assignment). Plus, symbols are more confusing for people to learn about than words. There are lots of people who are fluent in English, but dislike math. So, I opted for a simple, unambiguous, non-mathematical way of expressing "assignment" which makes sense even to the non- mathematically inclined: Set x to 8. That way, = can be reserved unambiguously and unconfusingly for the mathematical notion of "equality" -- because it's in their math classes that people learn what = means: Set QuadraticEquation to a*x^2 + b*x + c = 0. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 10:00 am, "Dan Upton" <[EMAIL PROTECTED]> wrote: > Sounds to me like the teacher is being difficult, ... No, proof-by-contradiction is a common technique in math. If you can show that x=8 and x=10, then you have shown that your assumptions were incorrect. > If you can't do, or don't like, math, you probably shouldn't be > programming. Why not? Recipes are programs. I prefer to look at it the other way: an easy-to-use programming language might encourage more people to like math. > You keep trotting out this quadratic equation example, but does FT > actually have any kind of useful equation solver in it? Not yet, but it will. Probably around July. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 1:14 pm, MRAB <[EMAIL PROTECTED]> wrote: > I wonder whether "is" could be used both for "x is value" and "x is a > type" without causing a problem: > > If command is a string ... > > If command is "quit" ... I think you are right. I like "If command is "quit" ...". For a user who wasn't mathemetically inclined and was doing mainly string manipulation, I think it might be easier to read than the equivalent "If command = "quit" ...". By making them exactly equivalent, I can't think of any confusion that might induce bugs. If you think of any drawbacks, please let me know. Otherwise, I'll put it in the next time I update the parser (probably this weekend). Thank you again for your suggestions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 1:29 pm, "Dan Upton" <[EMAIL PROTECTED]> wrote: > ... --somewhat akin to the > guy who a month or so ago wanted to sneakily teach his high school > class programming fundamentals by teaching them game programming. Yep, that's kind of my plan, too. After I get enough "computer languagey" stuff running, I'm going to incorporate the 3D graphics from DPGraph. > Maybe this should be your selling point, and maybe you should be > drawing comparisons to programming in Matlab or Mathematica. That sounds like a good idea. Personally, the first thing I wanted to get running in Flaming Thunder was the ability to cross-compile CGI scripts for Linux under Windows, because some inexpensive web-hosting sites (such as GoDaddy) don't allow shell access, so I couldn't compile the CGI scripts natively. Also, the ability to cross-compile programs for the Mac since Macs often appear in educational settings. Now that those are up and running and Flaming Thunder is released to the public, I'm adding features as prioritized by customer requests. Currently, the highest big things on the list are arrays/matrices and 3D graphics. Next on the list is improved symbolics. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On May 21, 12:38 pm, Mark Dickinson <[EMAIL PROTECTED]> wrote: > >>> a+0.999 # gives expected result > 9998.0 > >>> a+0. # doesn't round correctly. > > 1.0 Shouldn't both of them give .0? I wrote the same program under Flaming Thunder: Set a to 10^16-2.0. Writeline a+0.999. Writeline a+0.. and got: 9998.999 9998. I then set the precision down to 16 decimal digits to emulate Python: Set realdecimaldigits to 16. Set a to 10^16-2.0. Writeline a+0.999. Writeline a+0.. and got: .0 .0 -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On May 21, 2:44 pm, "Jerry Hill" <[EMAIL PROTECTED]> wrote: > My understand is no, not if you're using IEEE floating point. Yes, that would explain it. I assumed that Python automatically switched from hardware floating point to multi-precision floating point so that the user is guaranteed to always get correctly rounded results for +, -, *, and /, like Flaming Thunder gives. Correct rounding and accurate results are fairly crucial to mathematical and scientific programming, in my opinion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On May 21, 3:17 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > If you're going to use every post and question about Python as an > opportunity to pimp your own pet language you're going irritate even > more people than you have already. Actually, I've only posted on 2 threads that were questions about Python -- this one, and the one about for-loops where the looping variable wasn't needed. I apologize if that irritates you. But maybe some Python users will be interested in Flaming Thunder if only to check the accuracy of the results that they're getting from Python, like I did on this thread. I think most people will agree that having two independent programs confirm a result is a good thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On May 21, 3:19 pm, "Dan Upton" <[EMAIL PROTECTED]> wrote: > The fact is, sometimes it's better to get it fast and be good enough, > where you can use whatever methods you want to deal with rounding > error accumulation. I agree. I also think that the precision/speed tradeoff should be under user control -- not at the whim of the compiler writer. So, for example, if a user says: Set realdecimaldigits to 10. then it's okay to use hardware double precision, but if they say: Set realdecimaldigits to 100. then it's not. The user should always be able to specify the precision and the rounding mode, and the program should always provide correct results to those specifications. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On May 21, 3:41 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > When told why you got different results (an answer you > probably already knew, if you know enough about IEEE to do the > auto-conversion you alluded to) ... Of course I know a lot about IEEE, but you are assuming that I also know a lot about Python, which I don't. I assumed Python was doing the auto-conversion, too, because I had heard that Python supported arbitrary precision math. Jerry Hill explained that you had to load a separate package to do it. > you treated it as another opportunity > to (not very subtly) imply that Python was doing the wrong thing. This person who started this thread posted the calculations showing that Python was doing the wrong thing, and filed a bug report on it. If someone pointed out a similar problem in Flaming Thunder, I would agree that Flaming Thunder was doing the wrong thing. I would fix the problem a lot faster, though, within hours if possible. Apparently this particular bug has been lurking on Bugzilla since 2003: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On May 21, 4:21 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > Which is exactly what the python decimal module does. Thank you (and Jerry Hill) for pointing that out. If I want to check Flaming Thunder's results against an independent program, I'll know to use Python with the decimal module. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 21, 7:49 pm, MRAB <[EMAIL PROTECTED]> wrote: > I've thought of one possible drawback: "a" and "an" can be used as > variables, so the "is a" part might cause a problem. You'd need to > check the parser to find out... Good point, I hadn't noticed that. I'll check it out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On May 21, 7:01 pm, Carl Banks <[EMAIL PROTECTED]> wrote: > The crucial thing is not to slow down the calculations with useless > bells and whistles. Are you running your simulations on a system that does or does not support the "useless bell and whistle" of correct rounding? If not, how do you prevent regression towards 0? For example, one of the things that caused the PS3 to be in 3rd place behind the Wii and XBox 360 is that to save a cycle or two, the PS3 cell core does not support rounding of single precision results -- it truncates them towards 0. That led to horrible single-pixel errors in the early demos I saw, which in term helped contribute to game release delays, which has turned into a major disappointment for Sony. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> Does this mean that Flaming Thunder requires explicit checking rather > than offering exceptions? Right now, yes, Flaming Thunder has minimal error handling. But error handling is rising on the list of priorities for the next few weeks (arrays, matrices, and 3D graphics are the hightest). I think in a month or two, Flaming Thunder will be using catch/throw exception and error handling. So, for example: Set result to catch(read x from "input.txt".). If result is an error then go to quit. If not caught, errors will propagate up and if they they hit the top level, cause the program to write an error message and exit. Using only catch instead of try/catch has several advantages that I can see. 1) it gets rid of all the impotent try/catch/throw statements cluttering up Java, etc. 2) since all Flaming Thunder statements return values (like C statements), Catch also gives you a single, uniform, syntactically unambiguous way to embed statements (or whole statement lists) into expressions -- without causing the syntactic problems of = statements in if statements or the obfuscation of question mark notation, etc. For example: If catch(set x to y+z.) < 0.1 then go to tinyanswer. On May 22, 4:19 pm, Brian Quinlan <[EMAIL PROTECTED]> wrote: > Dave Parker wrote: > >> Or just: > > >> If command is "quit" ... > > > Hmmm. In Flaming Thunder, I'm using "is" (and "is an", "is a", etc) > > for assigning and checking types. For example, to read data from a > > file and check for errors: > > > Read data from "input.txt". > > If data is an error then go to ... > > Hey Dave, > > Does this mean that Flaming Thunder requires explicit checking rather > than offering exceptions? > > Cheers, > Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> That error message is the erlang interpreter saying "Hey I know X is > 8, and you've said it is 10 - that can't be right", which is pretty > much what math teachers say too... I enjoyed the discussion of how different languages handle the notion of "="; I learned something new. Thanks. On May 22, 9:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: > Dave Parker <[EMAIL PROTECTED]> wrote: > > But after getting input from children and teachers, etc, it started > > feeling right. > > > For example, consider the two statements: > > > x = 8 > > x = 10 > > > The reaction from most math teachers (and kids) was "one of those is > > wrong because x can't equal 2 different things at the same time". > > This is a common feature in functional languages... > > Eg > > Erlang (BEAM) emulator version 5.6.2 [source] [smp:2] > [async-threads:0] [kernel-poll:false] > > Eshell V5.6.2 (abort with ^G) > 1> X = 8. > 8 > 2> X = 10. > ** exception error: no match of right hand side value 10 > 3> > > That error message is the erlang interpreter saying "Hey I know X is > 8, and you've said it is 10 - that can't be right", which is pretty > much what math teachers say too... > > -- > Nick Craig-Wood <[EMAIL PROTECTED]> --http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
> > If catch(set x to y+z.) < 0.1 then go to tinyanswer. > > So what does this do exactly if the set throws an error? I think the catch should catch the error thrown by set, compare it to 0.1, the comparison will not return true because the error is not less than 0.1, and so the go-to to tinyanswer will not be taken. > Is the error > message printed at the top level going to be telling you about the failed > addition or the failed comparison? I don't think there will be an error message at the top in the case above, because I don't think the comparison should fail -- the comparision will return that it is not true that the error is less than 0.1. > Why do you need the catch anyway, if a > statement is just an expression why can't you just put the statement into > parentheses? Statements return values, but statements are not just expressions. Statements are more about control-flow and side-effects; expressions are more about returning values. Putting a statement into parentheses in a context where expressions are also allowed in parentheses is (or can be) both lexically and visually ambiguous. That's why C had to resort to the confusing "=" vs "==" notation -- to disambiguate the two cases. The "catch" keyword unambiguously alerts the reader that the parenthesis contain a statement (or a whole list of statements). > For that matter, is there any way to distinguish between different errors > and only catch particular ones? I think the catch function should catch all of the errors (and the non- error result if no error occured), so I think distinguishing the error would have to come after. Maybe something like: Set result to catch(read x from "input.txt".). If result = dividebyzeroerror then ... else throw result. I'm open to alternate suggestions, though. > You have a great opportunity to avoid making some of the same mistakes that > Python is trying to get out of. I'm sure that I'll make my own new and different errors. :) However, I really appreciate your comments because maybe I'll make fewer errors. Or at least, correct them faster. On May 28, 7:52 am, Duncan Booth <[EMAIL PROTECTED]> wrote: > Dave Parker <[EMAIL PROTECTED]> wrote: > > Catch also gives you a > > single, uniform, syntactically unambiguous way to embed statements (or > > whole statement lists) into expressions -- without causing the > > syntactic problems of = statements in if statements or the obfuscation > > of question mark notation, etc. For example: > > > If catch(set x to y+z.) < 0.1 then go to tinyanswer. > > So what does this do exactly if the set throws an error? Is the error > message printed at the top level going to be telling you about the failed > addition or the failed comparison? Why do you need the catch anyway, if a > statement is just an expression why can't you just put the statement into > parentheses? > > For that matter, is there any way to distinguish between different errors > and only catch particular ones? A bare except clause in Python is usually a > signal of bad code: when handling errors you only want the errors you have > anticipated, and want to be sure that any unexpected errors don't get > caught. > > You have a great opportunity to avoid making some of the same mistakes that > Python is trying to get out of. For example as of Python 2.5 > KeyboardInterrupt and SystemExit to longer inherit from Exception. That > means a bare except in Python no longer catches either of those: if you > want to handle either of these exceptions you have to be explicit about it. > > -- > Duncan Boothhttp://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 12:09 pm, Luis Zarrabeitia <[EMAIL PROTECTED]> wrote: > Following your posts in this thread, I see that > you 'plan to add soon' every cool feature that every other language seems to > have. I've already added a lot of them. For example, loops that don't need looping variables: For 1000 times do ... Explicit infinite loops: For forever do ... I don't those are features that every other language seems to have, not even Python. Plus, by this weekend, built-in compiled fullscreen 3D graphics will be in, too. > With no certainty whatsoever that today's program will work on > tomorrow's FT. Kind of like how this year's program won't work on next year's Python? Except Flaming Thunder is faster. ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 12:48 pm, "Dan Upton" <[EMAIL PROTECTED]> wrote: > there's no reason "set" itself > should throw any sort of error in the sense of an exception--in a > statement like "Set x to SomeFunctionThatCanBlowUp()", the semantics > should clearly be that the error comes from the function. In a simple > addition statement, that makes no sense. For example: Set z to catch(somefunctionthatmightblowup(...)). If catch(set x to y+z.) < 0.1 then go to tinyanswer. Or something like that. Or if you change the + to a / and z is 0.0, for example, then it could cause a divide-by-zero exception. There is no guarantee that the + won't cause an exception, given that there is no guarantee that y and z are both numeric. > However, I think overloading your catch error types to include objects > (or integral values, I guess, your example below isn't clear) along > with real values (ignoring the bit above about whether floating-point > assignment could throw an error) makes things confusing. Catch doesn't return just error types or numbers, it can return any object returned by the statements that are being caught; catch doesn't care what type they are. For example: Writeline catch(set x to "hello world".). will write "hello world". > It's nice > that "catch(stuff)" indicates that there's one or more statements > inside, but so does indentation in Python, bracketing in C/C++, > Begin/End in , and so forth, ... Except that in those languages, I don't think that the indentation, bracketing, Begin/End, etc, can be used in expressions. Catch can. For example, catch will return the final value of z: If catch(Set x to y+z. Set y to x+z. Set z to 1/(x+y).) < 0.1 then go to tinyanswer. > Beyond that, > I think you would want a good mechanism for comparing ranges of values > if you want to make exceptions/errors real-valued. I am thinking that exceptions/errors should have any kinds of values the programmer wants to give them. Some people prefer error numbers, some prefer error messages, some prefer error identifiers, etc. I am thinking that the Error function should simply take a list of whatever objects the user wants to throw, and throw them. For example, if the programmer wanted an error number and an error message for a particular error: If x < 10 then throw error(10, "Please enter a number >= 10"). They could then do something like: Set result to catch(funtionthatcouldblowup(...)). If result is an error then if result(1) = 10 then writeline result(2). Thank you for your comments, they are helping me to clarify my own thinking on error handling in general and on catch in particular. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On May 28, 3:19 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > Kind of like how this year's program won't work on next year's > > Python? > > For somebody who has admitted to have only very rudimentary knowledge of > python that's a pretty bold statement, don't you think? Everthing I know, I learned from Wikipedia. ;) http://en.wikipedia.org/wiki/Python_(programming_language)#Timeline_and_compatibility "Like Perl 6, Python 3.0 will break backward compatibility. There is no requirement that Python 2.x code will run unmodified on Python 3.0. There are basic changes such as changing the print statement into a print function (so any use of the print statement will cause the program to fail) ..." -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
Dan Upton wrote: > I just think if you're shooting for an easily understandable > language, overloading error handling requires more thought on the > programmer's part, not less, because they have to reason about all > outcomes Duncan Booth wrote: > Maybe FT should do something similar: >Writeline value of (set x to "hello world". Result is x.). I like the "value of" syntax. You guys have convinced me to reconsider overloading the error handling. Thank you both. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Jun 5, 7:57 am, "Dan Upton" <[EMAIL PROTECTED]> wrote: >... wait, x = 8 and x = 10! > But how can that be, Dave? You and your elementary kids just told me > I can't have two values for x... x = 8 OR x = 10. ;) By the way, realtime fullscreen 3D graphics are now up and running under Windows. Check out the News and Docs at http://www.flamingthunder.com/ On Jun 5, 7:57 am, "Dan Upton" <[EMAIL PROTECTED]> wrote: > On Thu, Jun 5, 2008 at 9:43 AM, John Salerno <[EMAIL PROTECTED]> wrote: > > "Dave Parker" <[EMAIL PROTECTED]> wrote in message > >news:[EMAIL PROTECTED] > > On May 20, 7:05 pm, Collin <[EMAIL PROTECTED]> wrote: > > > --- > > For example, consider the two statements: > > > x = 8 > > x = 10 > > > The reaction from most math teachers (and kids) was "one of those is > > wrong because x can't equal 2 different things at the same time". > > --- > > > Aw, come on. I'm a novice programmer but even after reading the most basic > > of introductions to a programming language I can tell that x is being > > assigned one value, then another. > > > It doesn't seem fair to take statements like the above out of the context of > > a program and then ask teachers and students about it. This statement: > > > 2 + 2 = 4 > > > means something in the context of an elementary math class, but is clearly > > not an assignment statement in Python. But I've never encountered anyone who > > was confused by this distinction, as long as you know where this line > > belongs. > > Yeah, that's sort of like I mentioned earlier in the thread about > there being a time dependence between the two. Not only that, but I > just realized that Dave has trotted out several times the notion of > representing (and solving) a quadratic equation in FT. Well, let's > see... (x-9)**2 - 1 = (too lazy to do the expansion to write in ax**2 > + bx + c format) = 0... solve solve solve... wait, x = 8 and x = 10! > But how can that be, Dave? You and your elementary kids just told me > I can't have two values for x... > > ;)- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Dynamic HTML from Python Script
On Jun 11, 7:59 am, Lie <[EMAIL PROTECTED]> wrote: > You can't make the browser refresh automatically in the server side, Yes you can. I don't know how to do it in Python, but here's an example in Flaming Thunder of a small, fast, light compiled server side CGI that delivers dynamic content every 10 seconds. # Write out the HTTP headers, followed by a blank line. # Make sure to write CRLF and not just LF, as per HTTP # specs. Also, turn off caching using the no-cache and # expires options, so that caching doesn't conflict with # refreshes. Set CRLF to CarriageReturn+LineFeed. Write "Refresh: 10; url=http://www.flamingthunder.com/cgi/ refresh.cgi",CRLF. Write "Content-type: text/html",CRLF. Write "Pragma: no-cache",CRLF. Write "Expires: 0",CRLF. Write "Cache-Control: no-cache",CRLF. Write CRLF. # Write out the dynamic information. In this # case, we'll just write out Greenwich mean time. Write GetGreenwichMeanTime. For this example, the dynamic content is just Greenwich mean time. You can see it in action at: http://www.flamingthunder.com/cgi/refresh.cgi To create the CGI script, I used Flaming Thunder's cross compiling ability to compile the script under Windows, targeting Linux: ft file refresh.ft output refresh.cgi target linux32 I then ftp'd refresh.cgi up to the cgi directory on my server, set the permissions to 700 to make it executable, and it works (without needing to install any bulky, plodding interpreter). On Jun 11, 7:59 am, Lie <[EMAIL PROTECTED]> wrote: > On Jun 11, 9:16 am, asdf <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 11 Jun 2008 11:20:48 +1000, Aidan wrote: > > > asdf wrote: > > >>> Well, there's a few ways you could approach it. > > > >>> You could create a cgi program from your script - this is probably the > > >>> solution you're looking for. > > > >> Output from the script does come up very often. There is a new output > > >> every 10 secs and it's possible that the script might be run > > >> indefinitely. Basically I want all that output displayed in a web > > >> browser > > > > Well, in that case you could simply append the new output to a static > > > file every 10 seconds, or whenever there is new output. That way, you > > > just need to refresh the static file in your browser to see updates... > > > Given what I understand of your situation, that's how I'd do it. > > > The problem with this is that browser would have to be refreshed manually > > every 10 seconds. Unless there is a way to set this in the script itself. > > Surely you don't think you can do that without Javascript don't you? > You can't make the browser refresh automatically in the server side, > it has to be done in the client side scripting or like Opera browser > that have an option to make it refresh a page every few seconds. > > > > > > A constantly running CGI app is probably not the best idea, given > > > timeouts and other such constraints you might run into. > > > >>> You could have the script run periodically and create a static html > > >>> file in the webroot... this would be acceptable, maybe preferable, if > > >>> the output from your script doesn't change frequently.- Hide quoted > > >>> text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Dynamic HTML from Python Script
On Jun 11, 10:43 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > Those are not /server side/ refreshes... Correct. But we weren't discussing server side refreshes. We were discussing how to make the "browser refresh automatically in the server side": On Jun 11, 7:59 am, Lie <[EMAIL PROTECTED]> wrote: > Surely you don't think you can do that without Javascript don't you? > You can't make the browser refresh automatically in the server side, > it has to be done in the client side scripting or like Opera browser > that have an option to make it refresh a page every few seconds. The example I posted showed a simple way to "make the browser refresh automatically in the server side" by using an HTTP Refresh header instead of using any Javascript or client side scripting or setting a browser option to refresh the page every few seconds. On Jun 11, 10:43 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > On Wed, 11 Jun 2008 07:36:59 -0700 (PDT), Dave Parker > <[EMAIL PROTECTED]> declaimed the following in > comp.lang.python: > > > Yes you can. I don't know how to do it in Python, but here's an > > example in Flaming Thunder of a small, fast, light compiled server > > side CGI that delivers dynamic content every 10 seconds. > > > # Write out the HTTP headers, followed by a blank line. > > # Make sure to write CRLF and not just LF, as per HTTP > > # specs. Also, turn off caching using the no-cache and > > # expires options, so that caching doesn't conflict with > > # refreshes. > > > Set CRLF to CarriageReturn+LineFeed. > > Write "Refresh: 10; url=http://www.flamingthunder.com/cgi/ > > refresh.cgi",CRLF. > > Those are not /server side/ refreshes... The first thing being > written is a command to the browser that tells the browser to reload the > specified page after a delay period. > > IOWs it is the browser doing the refresh -- which means it starts a > whole new connection, receiving a page from the CGI script... Said page > again having a browser command to do a delayed refresh. > > Server side would mean that the server somehow continuously sends > updates WITHOUT BEING ASKED. > -- > Wulfraed Dennis Lee Bieber KD6MOG > [EMAIL PROTECTED] [EMAIL PROTECTED] > HTTP://wlfraed.home.netcom.com/ > (Bestiaria Support Staff: [EMAIL PROTECTED]) > HTTP://www.bestiaria.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and Flaming Thunder
On Jun 7, 10:24 am, Sam Denton <[EMAIL PROTECTED]> wrote: > I've long believed that '=' should be banned from programming languages. > Use '==' for equality tests, and ':=' for assignments. That's an interesting suggestion that I don't recall hearing anyone else ever mention. On Jun 7, 10:24 am, Sam Denton <[EMAIL PROTECTED]> wrote: > John Salerno wrote: > > "Dave Parker" <[EMAIL PROTECTED]> wrote in message > >news:[EMAIL PROTECTED] > > On May 20, 7:05 pm, Collin <[EMAIL PROTECTED]> wrote: > > > --- > > For example, consider the two statements: > > > x = 8 > > x = 10 > > > The reaction from most math teachers (and kids) was "one of those is > > wrong because x can't equal 2 different things at the same time". > > --- > > > Aw, come on. I'm a novice programmer but even after reading the most basic > > of introductions to a programming language I can tell that x is being > > assigned one value, then another. > > I've long believed that '=' should be banned from programming languages. > Use '==' for equality tests, and ':=' for assignments.- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
