Re: Are Python's reserved words reserved in places they dont need to be?
Cliff Wells wrote: patch here: http://mail.python.org/pipermail/python-list/2001-June/047996.html Did you happen to remember this post or is Google *really* your friend? Have you taken The Oath? If not, I'm afraid I cannot tell you. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
On Wed, 13 Sep 2006 07:45:02 +, Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. [snip] Shrug, Different options are possible, in a file the keywords could just be prefixed with a Ctrl-K, and depending on the editor or its setting, this could be shown bold or blue or whatever. I don't care about the specifics at this point. I just wanted to make clear there is the option to make/show the distiction between identifiers and keywords more explicitly. But surely all you are doing is changing the reserved word from (say) return to \x0breturn. Once you do that, you can bet that people will complain that they want to have identifiers in bold too, why can't they create a name \x0breturn, and somebody will come up with an even more complicated scheme for accommodating them... wash, rinse, repeat. -- Steven D'Aprano -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need?tobe?
Delaney, Timothy (Tim) wrote: Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Exactly how am I supposed to use my text editor to make words bold? Is every text editor supposed to understand a python format for code? That's easy: bpass/b, breturn/b, ... Hmm, that's too verbose, maybe it would be better to do it just by appending a underscore to the word: pass_, return_, ... wink_ -- Roberto Bonvallet -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
One place where I would use such a feature is in a unittest package. I think being able to write self.assert or self.raise looks better than having to append an underscore. Maybe that is a good argumment for Py.Test ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
On 2006-09-14, Steven D'Aprano [EMAIL PROTECTED] wrote: On Wed, 13 Sep 2006 07:45:02 +, Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. [snip] Shrug, Different options are possible, in a file the keywords could just be prefixed with a Ctrl-K, and depending on the editor or its setting, this could be shown bold or blue or whatever. I don't care about the specifics at this point. I just wanted to make clear there is the option to make/show the distiction between identifiers and keywords more explicitly. But surely all you are doing is changing the reserved word from (say) return to \x0breturn. Once you do that, you can bet that people will complain that they want to have identifiers in bold too, why can't they create a name \x0breturn, and somebody will come up with an even more complicated scheme for accommodating them... wash, rinse, repeat. Do you really think this is a serious possibility? As far as I can see, that \x0b that will be prepended to differentiate keywords from identifiers is a technique called stropping, that has been used with some algol languages. Have you any knowledge of people programming algol who asked for the use of stropped identifiers? I think I really would be amazed to find out there were such people, but then I have been amazed before. So I really would like to know. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Carl Banks wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an identifier is used for class definition but class followed by equals is a simple assignment? Hmm. Someone called metaPERL is asking why Python doesn't have a more complicated grammar. Why does this not surprise me? :) Yeah. But elimination of all keywords and replacement by punctuation is clearly an alternative. One might just start with: @class X(object): @def __init__(self): @print an X and move on to: @% X(object): @_ _init__(self): an X That's all still LL(1) parsable. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
Antoon Pardon wrote: On 2006-09-14, Steven D'Aprano [EMAIL PROTECTED] wrote: On Wed, 13 Sep 2006 07:45:02 +, Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. But surely all you are doing is changing the reserved word from (say) return to \x0breturn. Once you do that, you can bet that people will complain that they want to have identifiers in bold too, why can't they create a name \x0breturn, and somebody will come up with an even more complicated scheme for accommodating them... wash, rinse, repeat. Do you really think this is a serious possibility? As far as I can see, that \x0b that will be prepended to differentiate keywords from identifiers is a technique called stropping, that has been used with some algol languages. Have you any knowledge of people programming algol who asked for the use of stropped identifiers? I think I really would be amazed to find out there were such people, but then I have been amazed before. So I really would like to know. Don't restrict yourself to something like that! Use HTML to indicate purpose of your python programs! So, your identifiers must be between b and /b tags. You strings will have to sit inside of a CDATA section to work right, and you get all sorts of entity substitutions for free! My program doesn't work anymore. Are your function names between h3 tags? (Secretly repulsed, yet fascinated) --Jason -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Paul Rubin wrote: Antoon Pardon [EMAIL PROTECTED] writes: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Heh, sounds like ColorForth, in which words meant different things depending on what color they were written in (www.colorforth.com). Madness, if you ask me ;-). Yikes! I'm color blind! (I've heard that 10% of the male population is color blind.) I'd be a very poor ColorForth programmer. =) -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Roy Smith wrote: As I remember, you didn't need the whitespace either. IIRC, your example above could have been written as: PROGRAMKWDS REALREAL,WRITE WRITE=1.0 REAL=2.0 WRITE(*,*)WRITE,REAL END It's stranger than that. FORTRAN 77 is insensitive to white space (other than inside character literals). So you could write the code like: P RO G RAM KW D S RE ALRE AL, WRITE WRITE = 1 . 0 RE AL=2.0 WRI TE(* , *)WRI TE, REAL E N D if you wanted to ;-) When people complain that Python is sensitive to white space, remember this as the opposite extreme! [Just for completeness I will add that there are rules about what columns the code has to be in, but that is separate from the white space issue.] -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
On 2006-09-13, Carl Banks [EMAIL PROTECTED] wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an identifier is used for class definition but class followed by equals is a simple assignment? Hmm. Someone called metaPERL is asking why Python doesn't have a more complicated grammar. Why does this not surprise me? :) Would a solution for this always make the grammer more complicated? Seriously, Python is that way deliberately. The developers consider it a good design to reserve keywords. It is not in any way considered a flaw, nor an oversight, nor a case of laziness. Besides, what you ask is impossible in general. Consider this code: return(1,2,3) This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Are you returning the tuple (1,2,3), or are you calling the function return with arguments 1,2,3? There is no context-free grammar in the universe that can divine which one is meant. It'd have to use context to even guess, and in a highly dynamic language like Python, you can never be wholly sure of the context. (Is there an identifier named return in scope? Don't know until you run the code...) With my idea, you would just look whether return was written in bold or not. Also, I had a bug where I tried to set the attributes user and pass in an object but pass would not work because it is a reserved word. Again pass should be reserved in certain contexts but not others. Is Python 3k going to fix this sort of thing? Nope. PEP 3099 (which lists changes that won't be made in Python 3000), states that the Python grammar will not be more complex than LL(1), and says that simple grammars are more desirable than complex ones. There is no hope of this being fixed. This idea won't make python more complex than LL(1). -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
RE: Are Python's reserved words reserved in places they dont need tobe?
Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Exactly how am I supposed to use my text editor to make words bold? Is every text editor supposed to understand a python format for code? Besides, I don't like bold for keywords (or anything in code) - I like my keywords blue (RGB 0, 0, 255). Of course, with a python format, I could make *my* keywords blue. But I can pretty much guarantee that my preferred editor will not ever understand python format. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Antoon Pardon [EMAIL PROTECTED] writes: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Heh, sounds like ColorForth, in which words meant different things depending on what color they were written in (www.colorforth.com). Madness, if you ask me ;-). -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
On 2006-09-13, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Exactly how am I supposed to use my text editor to make words bold? Is every text editor supposed to understand a python format for code? The standard answer here to people complaining about their editor not working well with python is that they should use a better editor. Besides, I don't like bold for keywords (or anything in code) So? I don't like to append an _ to make a reserved keyword into an identifier. What individual people like or not is not a big concern. - I like my keywords blue (RGB 0, 0, 255). Of course, with a python format, I could make *my* keywords blue. But I can pretty much guarantee that my preferred editor will not ever understand python format. Shrug, Different options are possible, in a file the keywords could just be prefixed with a Ctrl-K, and depending on the editor or its setting, this could be shown bold or blue or whatever. I don't care about the specifics at this point. I just wanted to make clear there is the option to make/show the distiction between identifiers and keywords more explicitly. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
RE: Are Python's reserved words reserved in places they dont need tobe?
Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Exactly how am I supposed to use my text editor to make words bold? Is every text editor supposed to understand a python format for code? I guess you would do it the same way other languages have implemented this in the past: use bold if your editor supports it and use something else if it doesn't. Algol 68 has the concept that keywords and identifiers with the same spelling are distinguished in some way (and if I remember correctly there were compiler options that let you specify what sort of stropping you were using). There was case stropping: case not otherwise being significant you could indicate a reserved word by uppercasing it e.g. BEGIN; or various punctuation conventions .begin. 'BEGIN' @begin or your editor might indicate reserved words using a different font e.g. bold. I see wikipedia's entry on stropping says that Atlas Autocode let you strop keywords by underlining them using backspace and overstrike. That must have been real fun to type. One of the big advantages of stropping is of course that you don't have to print or view source code using the same convention as you used when entering the text. So you might use case stropping to type your source code in, but then print listings with keywords bolded and lowercased. So for Python you would have a magic comment similar to how you specify encoding to specify the type of stropping in use and your editor would recognise the comment and display the file using whichever stropping convention you prefer for viewing. Personally I think a simpler idea to get round clashes of reserved words and identifiers would be to adopt something similar to c#'s @ escape. You could simply allow the lexer to accept @'something' as an alternative spelling for the identifier something, but with no restrictions on the characters that such an identifier could contain. so for manipulating html you would be able to write: element.@'class' = whatever instead of having to call setattr or use some other kludge. If Python did have a mechanism like this to escape identifiers then you could implement stropping completely outside the language: you could have an editor which displays keywords in one font and identifiers in another (as most editors already do), and then when saving simply escape any identifiers which are not otherwise valid. It wouldn't even be a big change: the editor could probably guess your intent correctly 99% of the time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
On 2006-09-13, Paul Rubin http wrote: Antoon Pardon [EMAIL PROTECTED] writes: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Heh, sounds like ColorForth, in which words meant different things depending on what color they were written in (www.colorforth.com). Madness, if you ask me ;-). Well I'm sure people would be able the abuse the feature with madness as a result. However that is nothing new. One place where I would use such a feature is in a unittest package. I think being able to write self.assert or self.raise looks better than having to append an underscore. I once experimented with end markers in python, but I dropped it because end.if wasn't legal python. If python would make this distinction, one wouldn't need to be concerned anymore that the introduction of a new keyword would break code. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Antoon Pardon wrote: One place where I would use such a feature is in a unittest package. I think being able to write self.assert or self.raise looks better than having to append an underscore. patch here: http://mail.python.org/pipermail/python-list/2001-June/047996.html /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
Delaney, Timothy (Tim) wrote: Antoon Pardon wrote: This is just an idea of mine, nothing I expect python to adapt. But just suppose the language allowed for words in bold. A word in bold would be considered a reserved word, a word in non bold would be an identifier. Exactly how am I supposed to use my text editor to make words bold? Is every text editor supposed to understand a python format for code? Besides, I don't like bold for keywords (or anything in code) - I like my keywords blue (RGB 0, 0, 255). Of course, with a python format, I could make *my* keywords blue. But I can pretty much guarantee that my preferred editor will not ever understand python format. This would take us back to the days of Algol 60, where keywords could either be stropped (with single quotes, IIRC) or in some implementations underlined. I believe that Flexowriters had an underline key that didn't move the carriage, but it's all a long time ago now. But I guess we could use the dollar sign to indicate keywords without requiring too much of people's editors. $class$ sample1 $def$ __init__(self, a, b): self.a = a self.b = b $def$ __cmp__(self, other): $return$ self.a.__cmp__(other.a) Don't see *that* catching on, though ... regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
Exactly how am I supposed to use my text editor to make words bold? Is every text editor supposed to understand a python format for code? The standard answer here to people complaining about their editor not working well with python is that they should use a better editor. In general, that is true for the 21st century. But under certain circumstances, one might be forced to use a vi over a limited b/w terminal to fix that goddamn bug on the live system. Even though you don't care about the pesky details, it boils down to introducing an escape mechanism that will surround whatever identifiers there are. Which looks crap in anything except and python-aware editor. But I bet you don't work with e.g. subversion to display diffs and the like... Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
On 2006-09-13, Diez B. Roggisch [EMAIL PROTECTED] wrote: Exactly how am I supposed to use my text editor to make words bold? Is every text editor supposed to understand a python format for code? The standard answer here to people complaining about their editor not working well with python is that they should use a better editor. In general, that is true for the 21st century. But under certain circumstances, one might be forced to use a vi over a limited b/w terminal to fix that goddamn bug on the live system. AFAIR, even those terminals had a form of highlighting. And personnaly I would think PEP 0263 would be potentially more annoying than this idea in those circumstances. Even though you don't care about the pesky details, it boils down to introducing an escape mechanism that will surround whatever identifiers there are. Which looks crap in anything except and python-aware editor. But I bet you don't work with e.g. subversion to display diffs and the like... I wouldn't be surprised that looking at diffs from files that use PEP 0263 could look like crap too. Yes some decisions can cause some tools to be less usefull. I would say that the right cause of action is then to adapt those tools. Not to let something like that stop your decision. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
In general, that is true for the 21st century. But under certain circumstances, one might be forced to use a vi over a limited b/w terminal to fix that goddamn bug on the live system. AFAIR, even those terminals had a form of highlighting. And personnaly I would think PEP 0263 would be potentially more annoying than this idea in those circumstances. How so? Because some less important string literals might be fucked up? Certainly can that cause trouble, but having the trouble for each and every keyword is a huge difference. Even though you don't care about the pesky details, it boils down to introducing an escape mechanism that will surround whatever identifiers there are. Which looks crap in anything except and python-aware editor. But I bet you don't work with e.g. subversion to display diffs and the like... I wouldn't be surprised that looking at diffs from files that use PEP 0263 could look like crap too. Yes some decisions can cause some tools to be less usefull. I would say that the right cause of action is then to adapt those tools. Not to let something like that stop your decision. The same reasoning as above applies. And sure you would say that - the day you admit to have suggested a stupid thing won't be in my hopefully long-standing life span. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need tobe?
On 2006-09-13, Diez B. Roggisch [EMAIL PROTECTED] wrote: In general, that is true for the 21st century. But under certain circumstances, one might be forced to use a vi over a limited b/w terminal to fix that goddamn bug on the live system. AFAIR, even those terminals had a form of highlighting. And personnaly I would think PEP 0263 would be potentially more annoying than this idea in those circumstances. How so? Because some less important string literals might be fucked up? Certainly can that cause trouble, but having the trouble for each and every keyword is a huge difference. Viewing such an unimportant string literal might lockup your terminal, because your terminal interprets it as somekind of control sequence. Your keyword trouble would probably be less than looking at html code in those circumstances. Even though you don't care about the pesky details, it boils down to introducing an escape mechanism that will surround whatever identifiers there are. Which looks crap in anything except and python-aware editor. But I bet you don't work with e.g. subversion to display diffs and the like... I wouldn't be surprised that looking at diffs from files that use PEP 0263 could look like crap too. Yes some decisions can cause some tools to be less usefull. I would say that the right cause of action is then to adapt those tools. Not to let something like that stop your decision. The same reasoning as above applies. And sure you would say that - the day you admit to have suggested a stupid thing won't be in my hopefully long-standing life span. That you don't like it, is not the same as stupid. Your two arguments against, have nothing to do with the quality of the suggestion within the langauge but only with problems of the envinronment. You know, if I want, I can probably turn up some old terminal where you can only type uppercase letters. What if under certain circumstance I would be forced, to use this old thing. Would I then have a rightfull complaint against python because it is case significant? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an identifier is used for class definition but class followed by equals is a simple assignment? Also, I had a bug where I tried to set the attributes user and pass in an object but pass would not work because it is a reserved word. Again pass should be reserved in certain contexts but not others. Is Python 3k going to fix this sort of thing? I can give you a categorical NO to that one. Unless Guido changes his mind, and it's very unlikely, the answer is in PEP 3099: Things that will not change in Python 3000. It says: The parser won't be more complex than LL(1). He does not want to start down the slippery slope that leads to certain unnamed languages such as Perl. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
One way to avoid the issue I brought up is for the syntax to be very regular... like Lisp or Tcl: set class algebra (setq class algebra) -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
On 2006-09-13, metaperl [EMAIL PROTECTED] wrote: One way to avoid the issue I brought up is for the syntax to be very regular... like Lisp or Tcl: set class algebra (setq class algebra) Unfortunately (or fortunately?) the human mind isn't very regular and seems to prefer structured, redundant, and irregular languages. One might suppose it makes pattern recognition by neural networks easier. -- Grant Edwards grante Yow! I am having a at CONCEPTION-- visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
On Wed, 2006-09-13 at 10:30 +0200, Fredrik Lundh wrote: Antoon Pardon wrote: One place where I would use such a feature is in a unittest package. I think being able to write self.assert or self.raise looks better than having to append an underscore. patch here: http://mail.python.org/pipermail/python-list/2001-June/047996.html Did you happen to remember this post or is Google *really* your friend? Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl schrieb: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an identifier is used for class definition but class followed by equals is a simple assignment? Also, I had a bug where I tried to set the attributes user and pass in an object but pass would not work because it is a reserved word. Again pass should be reserved in certain contexts but not others. Most parsers are written in a way that makes keywords reserved, regardless of their occurrence. That is because it is way easier to do so. And the few reserved words won't matter usually. Is Python 3k going to fix this sort of thing? Don't think so. Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Why isn' t the parser smart enough to see that class followed by an identifier is used for class definition but class followed by equals is a simple assignment? Because it's simpler to reserve words than worry about possible ambiguities in all past and future use cases. If you could use it as an identifier, it wouldn't be a reserved word by the normal definition of the term. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... Take solace in the fact that you've been immediately notifed of the error while its fix: renaming pass to passwd is trivial ... i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Istvan Albert wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... Take solace in the fact that you've been immediately notifed of the error while its fix: renaming pass to passwd is trivial ... The error message is not very explicit - class is a reserved word will make far more sense to a new programmer than SyntaxError. Especially since the expression is rather innocent looking and correct-looking. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Diez B. Roggisch wrote: metaperl schrieb: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an the few reserved words won't matter usually. woe be unto the ORMs who try to map database columns to Python attributes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Istvan Albert wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... You are missing the point: the point is that the above could be considered correct if the rules of Python were that an assignment statement takes IDENTIFIER '=' LVALUE Also class IDENTIFIER COLON could also be considered correct. Take solace in the fact that you've been immediately notifed of the error while its fix: renaming pass to passwd is trivial ... Again in certain automatic mapping circumstances (ORMs being the most obvious, CSV to Python data another), it is not always convenient or desirable or semantically articulate to do so. i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl wrote: Istvan Albert wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... Take solace in the fact that you've been immediately notifed of the error while its fix: renaming pass to passwd is trivial ... The error message is not very explicit - class is a reserved word will make far more sense to a new programmer than SyntaxError. Especially since the expression is rather innocent looking and correct-looking. Well maybe, but one might as well have the interpreter complain that '= is an invalid class name'. Once an unmatchable token is encountered which parsing it's often difficult from inside the parser to determine exactly what the programmer's intent was. Otherwise you could try and fix the error, like the PL/1 F-level compiler used to. This would usually work when all that was wrong was a missing semicolon, but it frequently went completely berserk in other cases, leading to strange and implausible error reports. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl wrote: Istvan Albert wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... You are missing the point: the point is that the above could be considered correct if the rules of Python were that an assignment statement takes IDENTIFIER '=' LVALUE Also class IDENTIFIER COLON could also be considered correct. Yes it could but it isn't and isn't likely to be. Simply do not use reserved words. That rule is hardly limited to Python. Robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
On Tue, 2006-09-12 at 18:05 -0700, Robert Hicks wrote: metaperl wrote: Istvan Albert wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... You are missing the point: the point is that the above could be considered correct if the rules of Python were that an assignment statement takes IDENTIFIER '=' LVALUE Also class IDENTIFIER COLON could also be considered correct. Yes it could but it isn't and isn't likely to be. Simply do not use reserved words. That rule is hardly limited to Python. I'm surprised so many people misunderstand his complaint. It isn't as simple as don't do it. The OP is referring to autogenerated code and attributes. This means you must tell the source of the generated items (perhaps a database table) that it can't have a column named class or pass or add hacks in to work around it (an easy one would be to prefix autogenerated attributes, which also helps work around the lack of private attributes in Python). Whether or not this should be changed is tangential to the OP's point. It must be a bit frustrating to state the obvious over and over and see it misinterpreted each time. Python has shortcomings. This is one of them, whether there's valid reasons for it or not. It's better to acknowledge it and offer something useful rather than that isn't the Python way, don't do it. Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an identifier is used for class definition but class followed by equals is a simple assignment? Hmm. Someone called metaPERL is asking why Python doesn't have a more complicated grammar. Why does this not surprise me? :) Seriously, Python is that way deliberately. The developers consider it a good design to reserve keywords. It is not in any way considered a flaw, nor an oversight, nor a case of laziness. Besides, what you ask is impossible in general. Consider this code: return(1,2,3) Are you returning the tuple (1,2,3), or are you calling the function return with arguments 1,2,3? There is no context-free grammar in the universe that can divine which one is meant. It'd have to use context to even guess, and in a highly dynamic language like Python, you can never be wholly sure of the context. (Is there an identifier named return in scope? Don't know until you run the code...) Also, I had a bug where I tried to set the attributes user and pass in an object but pass would not work because it is a reserved word. Again pass should be reserved in certain contexts but not others. Is Python 3k going to fix this sort of thing? Nope. PEP 3099 (which lists changes that won't be made in Python 3000), states that the Python grammar will not be more complex than LL(1), and says that simple grammars are more desirable than complex ones. There is no hope of this being fixed. In fact, the opposite is going to happen: the one keyword that can currently moonlight as a symbol, as, is going to become a full-time keyword in Python 3000. woe be unto the ORMs who try to map database columns to Python attributes. A ha. First of all, consider whether you ought to be using dictionary keys instead. That is, columns[Name] rather than columns.Name. It most cases keys are preferrable, because unless you know what the columns are ahead of time, you'll be using getattr and setattr to get at the attributes, which defeats the whole point of attributes. (And if you do know what the columns are ahead of time, no need to automatically map the names.) The one legitimate use case I can think of for wanting to use attributes instead of keys is if you intend to have user-supplied Python code operating on the columns (and even then you should consider whether the user would be better off using keys). In this case you're pretty much stuck with workarounds. You can automatically rename any keywords when mapping the column names, and advise the user that colums with keyword names will have (for example) and appended underscore: import keyword def column_attribute_name(name): if keyword.iskeyword(name): return %s_ % name return name Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl [EMAIL PROTECTED] wrote: Yes, keywords are always reserved. The one major language that tried to do otherwise was PL/I, where you could code, e.g.: if if = if then then = else else else = if ((of course, '=' was also polimorpically read as either assignment OR comparison -- I gather that most Basic dialects still do that!-)). IBM (PL/I's inventor and rabid defender) found out the hard way that making the parser more complicated, slow and bug-prone in order to allow such absurd obfuscation was NOT a popular trade-off -- despite IBM's alleged monopoly power, PL/I is now basically dead while the older, crankier languages that PL/I wanted to replace, Cobol and particularly Fortran, are still quite alive (and with reserved words ALWAYS reserved -- like in C, Python, Java, C#, Haskell, and basically every language that's even halfway sensible;-). Is Python 3k going to fix this sort of thing? Fortunately not, or we'd all be busy studying Ruby or Boo!-) Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
metaperl [EMAIL PROTECTED] wrote: Diez B. Roggisch wrote: metaperl schrieb: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an the few reserved words won't matter usually. woe be unto the ORMs who try to map database columns to Python attributes. I'm gonna skip my usual anti-ORM rant, because there ARE valid case for mapping external names to Python identifiers -- e.g., remote protocols such as XML-RPC, automatic constructers of FF interfaces, etc. Such code generators -- targeting ANY language currently alive -- obviously have to possess some minimal knowledge of the target language's syntax, and the obvious solution is to systematically transform identifiers which would otherwise be keywords. The one most popular convention is to append an underscore -- so that 'pass' becomes 'pass_', and so on. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Steve Holden [EMAIL PROTECTED] wrote: Otherwise you could try and fix the error, like the PL/1 F-level compiler used to. This would usually work when all that was wrong was a missing semicolon, but it frequently went completely berserk in other Ah, yeah, I forgot that particularly endearing aspect of PL/I (to go with the language having no keywords) -- many compilers bent over backwards to double-guess what you meant, resulting in deep misunderstandings by many programmers about what the language was SUPPOSED to be, mysterious error messages and (worse!) program misbehavior, etc etc -- all, of course, at the price of making the compilers ever more intricate, bug-prone, extremely heavy in resource cosumption, slow, and laughably bad at optimization (when compared to compilers of the same era for sensibly SIMPLE languages, such as Fortran). Thanks for reviving the memories: it makes me SO ineffably glad that nowadays I'm using a language which, among its guiding principles, has in the face of ambiguity, refuse the temptation to guess!!!-) Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Alex Martelli) wrote: metaperl [EMAIL PROTECTED] wrote: Diez B. Roggisch wrote: metaperl schrieb: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Why isn' t the parser smart enough to see that class followed by an the few reserved words won't matter usually. woe be unto the ORMs who try to map database columns to Python attributes. I'm gonna skip my usual anti-ORM rant, because there ARE valid case for mapping external names to Python identifiers -- e.g., remote protocols such as XML-RPC, automatic constructers of FF interfaces, etc. Such code generators -- targeting ANY language currently alive -- obviously have to possess some minimal knowledge of the target language's syntax, and the obvious solution is to systematically transform identifiers which would otherwise be keywords. The one most popular convention is to append an underscore -- so that 'pass' becomes 'pass_', and so on. Alex Also, keywords are only reserved in the context of identifiers. They can certainly appear as string literals used as dictionary keys: attributes[class] = algebra -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Alex Martelli wrote: IBM (PL/I's inventor and rabid defender) found out the hard way that making the parser more complicated, slow and bug-prone in order to allow such absurd obfuscation was NOT a popular trade-off -- despite IBM's alleged monopoly power, PL/I is now basically dead while the older, crankier languages that PL/I wanted to replace, Cobol and particularly Fortran, are still quite alive (and with reserved words ALWAYS reserved -- like in C, Python, Java, C#, Haskell, and basically every language that's even halfway sensible;-). Except Fortran doesn't have any reserved words either: PROGRAM KWDS REAL REAL,WRITE WRITE=1.0 REAL=2.0 WRITE(*,*)WRITE,REAL END (Not sure whether it's true in Fortran 9x.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
Cliff Wells wrote: On Tue, 2006-09-12 at 18:05 -0700, Robert Hicks wrote: metaperl wrote: Istvan Albert wrote: metaperl wrote: -- python -i class = algebra File stdin, line 1 class = algebra ^ SyntaxError: invalid syntax Designing a syntax to avoid all possible newbie errors is impractical because as soon as you are finished with one iteration the new newbies will start making different kinds of errors... You are missing the point: the point is that the above could be considered correct if the rules of Python were that an assignment statement takes IDENTIFIER '=' LVALUE Also class IDENTIFIER COLON could also be considered correct. Yes it could but it isn't and isn't likely to be. Simply do not use reserved words. That rule is hardly limited to Python. I'm surprised so many people misunderstand his complaint. It isn't as simple as don't do it. The OP is referring to autogenerated code and attributes. This means you must tell the source of the generated items (perhaps a database table) that it can't have a column named class or pass or add hacks in to work around it (an easy one would be to prefix autogenerated attributes, which also helps work around the lack of private attributes in Python). Whether or not this should be changed is tangential to the OP's point. It must be a bit frustrating to state the obvious over and over and see it misinterpreted each time. Python has shortcomings. This is one of them, whether there's valid reasons for it or not. It's better to acknowledge it and offer something useful rather than that isn't the Python way, don't do it. Cliff -- Hi Cliff, You would also not be allowed to have a column name with a space,comma,*,;,... in them. It might be best to assume that column headings might end up with any arbitrary unicode character string and program from that. If the OP knows the full extent of his input data and knows that column names are valid identifiers PLUS Python reserved words then yes, It stops him from autogenerating identifiers in tht way - but others in this thread have suggested work-arounds. And yes, Python is not perfect, but its sweet spot is oh so tasty :-) (Which also applies to AWK, for a different sweet flavour) - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are Python's reserved words reserved in places they dont need to be?
In article [EMAIL PROTECTED], Carl Banks [EMAIL PROTECTED] wrote: Alex Martelli wrote: IBM (PL/I's inventor and rabid defender) found out the hard way that making the parser more complicated, slow and bug-prone in order to allow such absurd obfuscation was NOT a popular trade-off -- despite IBM's alleged monopoly power, PL/I is now basically dead while the older, crankier languages that PL/I wanted to replace, Cobol and particularly Fortran, are still quite alive (and with reserved words ALWAYS reserved -- like in C, Python, Java, C#, Haskell, and basically every language that's even halfway sensible;-). Except Fortran doesn't have any reserved words either: PROGRAM KWDS REAL REAL,WRITE WRITE=1.0 REAL=2.0 WRITE(*,*)WRITE,REAL END (Not sure whether it's true in Fortran 9x.) Carl Banks As I remember, you didn't need the whitespace either. IIRC, your example above could have been written as: PROGRAMKWDS REALREAL,WRITE WRITE=1.0 REAL=2.0 WRITE(*,*)WRITE,REAL END and worked just as well. I have nightmares thinking about writing a fortran parser. Oh yeah, spaces were the same as zeros on input, too. What a wonderful language. Isn't it wonderful how nothing you write ever gets lost once google gets it's hands on it: http://mirrorspace.org/python/doc/humor/index.html#habits (personally, I think the one about the little girl buying a wabbit in the pet store is the best of the collection). -- http://mail.python.org/mailman/listinfo/python-list
