Re: Another newbie design question
On Dec 20, 5:00 am, Paul McGuire <[EMAIL PROTECTED]> wrote: > On Dec 19, 10:48 am, [EMAIL PROTECTED] wrote: > > > This morning block comments disappeared from the Decaf design. Maybe > > later today they'll be instantiated in the tokenizer. > > Out of the idlest of curiousity, does this language have a BNF, or > some other form of grammar definition? > > -- Paul +1 Rhetorical Question OTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
On 2007-12-19, Paul McGuire <[EMAIL PROTECTED]> wrote: > On Dec 19, 10:48 am, [EMAIL PROTECTED] wrote: >> This morning block comments disappeared from the Decaf design. >> Maybe later today they'll be instantiated in the tokenizer. > > Out of the idlest of curiousity, does this language have a BNF, > or some other form of grammar definition? Might I suggest: laughs evilly, rubbing hands together? -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
On Dec 19, 10:48 am, [EMAIL PROTECTED] wrote: > This morning block comments disappeared from the Decaf design. Maybe > later today they'll be instantiated in the tokenizer. Out of the idlest of curiousity, does this language have a BNF, or some other form of grammar definition? -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
This morning block comments disappeared from the Decaf design. Maybe later today they'll be instantiated in the tokenizer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
> My 2 cents... Thanks for the feedback, Bruno. Seriously thinking about ditching the block comments and adding multi-line strings. (Block comments are the last item on my tokenizer's "todo" list. Multi-line strings would be easier.) Beginners will be programming fun things in a GUI environment. Think games. Brightly colored bouncing balls. Remember Pong? That's a Decaf- level program. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
[EMAIL PROTECTED] a écrit : (snip) > I'd like to hear from people who use Python's multi-line strings other > than in doc comments. Then: do you hear me ?-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
[EMAIL PROTECTED] a écrit : > Fortran (1957) had line comments. C (1972) replaced these with non- > nested block comments. C++ (1983) added here-to-EOL comments. Python > (1991) keeps here-to-EOL comments but replaces block comments with > multi-line quotes. Block comments and multi-line quotes both serve the > same purpose as doc comments. Block comments, especially if they nest, > are helpful for commenting out code. Multi-line quotes serve to add > text. > > Is Python, in this particular, an advance over C++? > > I wrote a lot of Java (here-to-EOL and block comments) without ever > feeling the need for multi-line quotes. I wrote a lot of Java without ever feeling the need for things functions as objects, lexical closures, lazy evaluation, anonymous functions etc. Then I learned to use these features and couldn't stand coding in Java no more. > I've written a little Perl and > found multi-line quotes useful for responding to -help switches. On > the other hand -help switches are very old-fashioned, a direction I'll > not be pointing my tiny beginner's language. "old-fashioned" ? Do you have something better to suggest ? Please keep in mind that most servers don't have GUIs (for obvious reasons). But multiline strings are not only useful for "old-fashioned -help switches" - they are useful anywhere you need a quick and simple text templating system - be it html, javascript, SQL, whatever - and using a full blown templating system would be overkill. IOW, like a lot of other features, it's not that you cannot do without, but it really helps when it's available *and* braindead easy to setup and use. My 2 cents... -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
Sion Arrowsmith wrote: > Given a one-or-the-other choice, any editor worth using can do > "comment/uncomment region", and if only to-EOL comments are > available, it will do that for you instead of using block > comments. So block comments are not really a useful language > feature. I'd expect the complete beginner to start in Notepad, and stay there for just long enough to realize that something better is needed. region commenting might be the perfect reason for upgrading. On the other hand, block comments are very useful for documentation. On the other, other hand, commenting out a region as the editors do makes it very obvious that the code is dormant. On yet another hand, editors also colorize, so the commented-out nature of block comments is apparent. There are other options. We could borrow and from HTML to have code and non-code regions. (In Java, where HTML is allowed in the doc comments, I wanted my editor to toggle between HTML editing and code editing. Not all wishes get fulfilled.) I'd like to hear from people who use Python's multi-line strings other than in doc comments. > What would you have to say about a language which > had no specialised comment syntax whatsoever, and expected > you to use semantically irrelevent string literals? I'd say the language predated Fortran, which means "Amazing" Grace Hopper wrote it. Perhaps A-0 didn't have comments? -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
<[EMAIL PROTECTED]> wrote: >I've designed a language, Decaf, for beginners. I've got block >comments but not multi-line strings. > >If you can only have one or the other, which is more helpful? Given a one-or-the-other choice, any editor worth using can do "comment/uncomment region", and if only to-EOL comments are available, it will do that for you instead of using block comments. So block comments are not really a useful language feature. Unless you're expecting your beginners to grind out their code in Notepad. On the other hand, they are completely orthogonal features. Multi-line strings in Python are not comments, and treating them as such is as misguided as using raw strings for Windows filenames. What would you have to say about a language which had no specialised comment syntax whatsoever, and expected you to use semantically irrelevent string literals? -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ "Frankly I have no feelings towards penguins one way or the other" -- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
Fortran (1957) had line comments. C (1972) replaced these with non- nested block comments. C++ (1983) added here-to-EOL comments. Python (1991) keeps here-to-EOL comments but replaces block comments with multi-line quotes. Block comments and multi-line quotes both serve the same purpose as doc comments. Block comments, especially if they nest, are helpful for commenting out code. Multi-line quotes serve to add text. Is Python, in this particular, an advance over C++? I wrote a lot of Java (here-to-EOL and block comments) without ever feeling the need for multi-line quotes. I've written a little Perl and found multi-line quotes useful for responding to -help switches. On the other hand -help switches are very old-fashioned, a direction I'll not be pointing my tiny beginner's language. (A brief article on programming language geneology is at http://www.MartinRinehart.com/articles/history-programming-languages.html .) -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
Original languages were line oriented, newer languages were block oriented. Original languages has line comments. Newer languages had block comments, and had line comments added back in. So I would read that as line comments being more fundamental, but people who used line comments got so sick of them that they thought block comments would be a good idea. (david) <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I've designed a language, Decaf, for beginners. I've got block > comments but not multi-line strings. > > If you can only have one or the other, which is more helpful? > > Should I have both? (Make a strong argument here: my design principal > is, "Designed by a backpacker: when in doubt, leave it out.") -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
Patrick Mullen a écrit : > On Dec 17, 2007 1:10 PM, Bruno Desthuilliers > <[EMAIL PROTECTED]> wrote: > > >>Hem... May I remind you that Python doesn't have block comments ?-) > > > I suppose we could argue semantics, since """ strings are actually > processed, You guessed !-) > but they are basically block comments. Nope, they are basically multiline strings. Their (not that wide AFAICT) use as block comments comes from both the docstrings stuff and the lack of block comments in Python. (snip) >>> However, inspection of a vast corpus of code might lead one >>>to believe that any commenting capability was completely unnecessary. > > > Lol! Who uses them dern comments anyway? Really, I wonder... -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
On Dec 17, 2007 1:10 PM, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Hem... May I remind you that Python doesn't have block comments ?-) I suppose we could argue semantics, since """ strings are actually processed, but they are basically block comments. So, there we are, multiline strings AND block comments! > > However, inspection of a vast corpus of code might lead one > > to believe that any commenting capability was completely unnecessary. Lol! Who uses them dern comments anyway? -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
Jim B. Wilson a écrit : > [EMAIL PROTECTED] wrote: > >> If you can only [block comments] or [multi-line strings] the other, >> which is more helpful? > > > I'm afraid no one would use a language that didn't feature block > comments. Hem... May I remind you that Python doesn't have block comments ?-) > However, inspection of a vast corpus of code might lead one > to believe that any commenting capability was completely unnecessary. +1 QOTW !-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Another newbie design question
[EMAIL PROTECTED] wrote: > If you can only [block comments] or [multi-line strings] the other, > which is more helpful? I'm afraid no one would use a language that didn't feature block comments. However, inspection of a vast corpus of code might lead one to believe that any commenting capability was completely unnecessary. > Should I have both? (Make a strong argument here: my design principal > is, "Designed by a backpacker: when in doubt, leave it out.") After my brief experience with Python, I don't think I'd advocate the removal of """'d strings. They come in quite handy in a lot of practical cases. And remember: "If you need it and you don't have it, you don't need it." (at least in backpacking :) Jim Wilson Gainesville, FL -- http://mail.python.org/mailman/listinfo/python-list
Another newbie design question
I've designed a language, Decaf, for beginners. I've got block comments but not multi-line strings. If you can only have one or the other, which is more helpful? Should I have both? (Make a strong argument here: my design principal is, "Designed by a backpacker: when in doubt, leave it out.") -- http://mail.python.org/mailman/listinfo/python-list
Re: [Newbie] design question
[EMAIL PROTECTED] wrote: > Suppose I have class ShoppingCart which has one method called > buy(), and class Buyer who has one reference to ShoppingCart... > Can I also have method buy() in class Buyer, which will then > called ShoppingCard.buy(), and also do some other stuff? Is this > legal design pattern, have methods with same name? In principle, this is legal. But OTOH, how could a ShoppingCart "buy" something? In my world, Buyers "buy" when using ShoppingCarts. Regards, Björn -- BOFH excuse #445: Browser's cookie is corrupted -- someone's been nibbling on it. -- http://mail.python.org/mailman/listinfo/python-list
Re: [Newbie] design question
> Suppose I have class ShoppingCart which has one method called buy(), > and class Buyer who has one reference to ShoppingCart... Can I also > have method buy() in class Buyer, which will then called > ShoppingCard.buy(), and also do some other stuff? Is this legal > design pattern, have methods with same name? Yes, something like this is perfectly fine. class ShoppingCart( object ): def buy( self ): print 'buy in shoppingcart' class Buyer( object ): def __init__( self, cart ): self.cart = cart def buy( self ): print 'buy in buyer' self.cart.buy( ) print 'some extra stuff' acart = ShoppingCart( ) abuyer = Buyer( cart=acart ) abuyer.buy( ) HTH, Daniel -- http://mail.python.org/mailman/listinfo/python-list
[Newbie] design question
Hi all Suppose I have class ShoppingCart which has one method called buy(), and class Buyer who has one reference to ShoppingCart... Can I also have method buy() in class Buyer, which will then called ShoppingCard.buy(), and also do some other stuff? Is this legal design pattern, have methods with same name? Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
