Re: as keyword woes
On 10 Des, 00:00, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: Go right ahead. Write your experimental language, and if people like it, they'll use it. That's what Guido did, all those years ago. But don't turn Python into a hodgepodge of features that most people consider misfeatures. If you consult the public record, you'll see that I'm probably more conservative than most when it comes to adding features. Indeed, one of the principal benefits I see in Python 3.0 is that the hordes of people wanting to add new stuff to Python will now focus on that flavour of the language and not Python 2.x. However, as I pointed out in another message, keyword conflicts have been a problem for the language designers for some time, and more powerful parser technology might have been able to help out. [...] I think it is childish to reject the Zen just because it's the Zen. Good advice doesn't cease to be good advice just because people tell you it's good advice, even if some people are awfully strident about it. I object to the Zen being trotted out every time someone questions any aspect of Python's design (language or implementation) which isn't being reworked elsewhere (say, in Python 3, where apparently the Zen can be suspended), especially when the parts of the Zen being quoted lack pertinence when compared to a properly formulated response to the original inquiry. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On 9 Des, 19:23, Chris Mellon [EMAIL PROTECTED] wrote: So hold up a second. I'm out of line for calling someone on making a trollish post that's not relevant to the topic, and for being pretty late to the party even with the part that *was* on topic, and for (even in the original post) going the ad-hominem route by not so subtly implying that Python is an ivory tower language that's not good I believe the term was ivory-tower thinking. enough for people with real problems - a clearly false statement by any standards, and doubly offensive from someone who *is* using it for real problems and who himself is a less than shining example of You're wide of the mark now, since the complainant was referring to motivations in the the design of the language, not the relevance of the language outside academia (where it is also highly relevant, by the way). responsible software management, but the OPs lapse into ranting in response to trite but accurate answers to a question he could have answered for himself, in detail, had he bothered to read the threads from the time when the issue actually matter is a reasonable response that we should support and validate? Trite but accurate? References to the Zen of Python were trite and peripheral at best, especially since the actual reasons (some actually being offered, aside from get used to it, which isn't a reason) are mostly pragmatic. I think at that point, the complainant is justified in questioning the priorities of the core developers, even though he knows that there's no recourse at this point. The most you can blame him for in that respect is not starting a new thread about those topics, and it's not as if he's the first to air his grievances about those things, is it? Sometimes you're not a crusader for thinking differently and change by confrontation and speaking truth to power. Sometimes you're just an asshole. I think you managed to enter this thread without revealing any particular insight in the matter, so I suppose name-calling was the most we could expect from you at this point. For clarification: The OPs original complaint is legitimate, if dated and partially his own fault. His phrasing of the problem, the tone and content of his email, and his lapse into flaming when he wasn't immediately hailed as a herald of sanity is not legitimate. If people would confine themselves to the matters under discussion without taking an adversarial position - after all, it's not as if the guy just dropped in to flame everyone having never used Python - there wouldn't be any need for anyone to lapse into flaming, tantrums or name-calling, would there? You wouldn't even need to apologise for calling the guy a troll, now, would you? Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Aaron Brady wrote: On Dec 9, 12:40 pm, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 8:28 am, MRAB [EMAIL PROTECTED] wrote: snip In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language). snip That is, 'certainly' doesn't change the meaning of your statement any. You wouldn't want it, but King George III didn't want the American Revolution. It's called emphasis. I just take you to have meant, then, +1 on excluding keywords from identifiers. You said it the long way though, so I thought I missed something deeper, that didn't come across. IIRC, most computer languages have an LL(1) grammar, which means that when they are parsed you need to look at only the next word. If you're about to parse a statement and the next word is IF then you know it's an IF-statement, if it's an identifier then it's either a call or an assignment statement (OK, you don't know exactly what kind of statement it is at that point, but it works out just fine!). In the example from PL/I, IF could be the start of an IF-statement IF condition THEN or an assignment statement IF = expression. It's a bit more tricky for the parser as well as the programmer. Life is easier if words having special meanings are reserved. However, that doesn't mean that all special words /must/ be reserved (pragmatism beats purity). Sometimes the syntax makes it clear and unambiguous, so you can get away with not making it a reserved word. The word as in Python doesn't need to be reserved because the syntax precludes ambiguity, but it's the only such word in the language, so it's just tidier to make it reserved too. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Lie a écrit : On Dec 7, 2:38 am, Warren DeLano [EMAIL PROTECTED] wrote: (snip) As someone somewhat knowledgable of how parsers work, I do not understand why a method/attribute name object_name.as(...) must necessarily conflict with a standalone keyword as . It seems to me that it should be possible to unambiguously separate the two without ambiguity or undue complication of the parser. (snip) And let things like: filelike.print('lpt') # python 2.6 zipper.with('7z') failure.try(alternative) executecodeobject.if(True) onfailure.break() ? As far as I'm concerned, I'd find this perfectly acceptable - there's no possible confusion here. Now this wouldn't be very practical, since you'd have to define the functions outside the class (with a valid identifier) then bind them to the class. But this is probably not going to happen anyway... -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, Dec 10, 2008 at 6:57 AM, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 12:40 pm, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 8:28 am, MRAB [EMAIL PROTECTED] wrote: snip In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language). snip That is, 'certainly' doesn't change the meaning of your statement any. You wouldn't want it, but King George III didn't want the American Revolution. It's called emphasis. I just take you to have meant, then, +1 on excluding keywords from identifiers. You said it the long way though, so I thought I missed something deeper, that didn't come across. IIRC, most computer languages have an LL(1) grammar, which means that when they are parsed you need to look at only the next word. If you're about to parse a statement and the next word is IF then you know it's an IF-statement, if it's an identifier then it's either a call or an assignment statement (OK, you don't know exactly what kind of statement it is at that point, but it works out just fine!). In the example from PL/I, IF could be the start of an IF-statement IF condition THEN or an assignment statement IF = expression. It's a bit more tricky for the parser as well as the programmer. Life is easier if words having special meanings are reserved. However, that doesn't mean that all special words /must/ be reserved (pragmatism beats purity). Sometimes the syntax makes it clear and unambiguous, so you can get away with not making it a reserved word. The word as in Python doesn't need to be reserved because the syntax precludes ambiguity, but it's the only such word in the language, so it's just tidier to make it reserved too. -- http://mail.python.org/mailman/listinfo/python-list I don't have a huge stake in this, but I wouldn't mind a change to allow anything proceeding a . or preceeding a ( to not be identified as a keyword. It is obvious to me a s a human reader that something.if is quite a bit different than just a bare if. And as far as parsing technology goes, isn't it supposed to go for the biggest match first? I would not be for allowing bare keywords to be used in the situations described above, but since we are so used to being able to being able to have say, myclass.dir() or myclass.len() without them overwriting the builtin functions, it makes sense to me to be able to define a myclass.as() or myclass.with() without overwriting the keywords. Though I know the semantics behind these two things are very different, the rules I go through when reading the code are very similar. The parser change might be a hassle, and it might not be worth it at all of course, but from a conceptual point of view it is simple. I mean, even now you can do class.__dict__[as]. I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword usage. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Patrick Mullen wrote: On Wed, Dec 10, 2008 at 6:57 AM, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 12:40 pm, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 8:28 am, MRAB [EMAIL PROTECTED] wrote: snip In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language). snip That is, 'certainly' doesn't change the meaning of your statement any. You wouldn't want it, but King George III didn't want the American Revolution. It's called emphasis. I just take you to have meant, then, +1 on excluding keywords from identifiers. You said it the long way though, so I thought I missed something deeper, that didn't come across. IIRC, most computer languages have an LL(1) grammar, which means that when they are parsed you need to look at only the next word. If you're about to parse a statement and the next word is IF then you know it's an IF-statement, if it's an identifier then it's either a call or an assignment statement (OK, you don't know exactly what kind of statement it is at that point, but it works out just fine!). In the example from PL/I, IF could be the start of an IF-statement IF condition THEN or an assignment statement IF = expression. It's a bit more tricky for the parser as well as the programmer. Life is easier if words having special meanings are reserved. However, that doesn't mean that all special words /must/ be reserved (pragmatism beats purity). Sometimes the syntax makes it clear and unambiguous, so you can get away with not making it a reserved word. The word as in Python doesn't need to be reserved because the syntax precludes ambiguity, but it's the only such word in the language, so it's just tidier to make it reserved too. I don't have a huge stake in this, but I wouldn't mind a change to allow anything proceeding a . or preceeding a ( to not be identified as a keyword. Don't you mean 'following a .'? IMHO if you forbid bar = True then you should also forbid foo.bar = True. As for preceding a (, what about the call if(True)? It looks like an if-statement! It is obvious to me a s a human reader that something.if is quite a bit different than just a bare if. And as far as parsing technology goes, isn't it supposed to go for the biggest match first? I would not be for allowing bare keywords to be used in the situations described above, but since we are so used to being able to being able to have say, myclass.dir() or myclass.len() without them overwriting the builtin functions, it makes sense to me to be able to define a myclass.as() or myclass.with() without overwriting the keywords. Though I know the semantics behind these two things are very different, the rules I go through when reading the code are very similar. The parser change might be a hassle, and it might not be worth it at all of course, but from a conceptual point of view it is simple. I mean, even now you can do class.__dict__[as]. I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword usage. Parsing isn't about the biggest match. Ideally you want something that's simple without being simplistic. Python is a good example. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, Dec 10, 2008 at 12:22 PM, Patrick Mullen [EMAIL PROTECTED]wrote: On Wed, Dec 10, 2008 at 6:57 AM, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 12:40 pm, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 8:28 am, MRAB [EMAIL PROTECTED] wrote: snip In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language)http://en.wikipedia.org/wiki/PL/I_%28programming_language%29 . snip That is, 'certainly' doesn't change the meaning of your statement any. You wouldn't want it, but King George III didn't want the American Revolution. It's called emphasis. I just take you to have meant, then, +1 on excluding keywords from identifiers. You said it the long way though, so I thought I missed something deeper, that didn't come across. IIRC, most computer languages have an LL(1) grammar, which means that when they are parsed you need to look at only the next word. If you're about to parse a statement and the next word is IF then you know it's an IF-statement, if it's an identifier then it's either a call or an assignment statement (OK, you don't know exactly what kind of statement it is at that point, but it works out just fine!). In the example from PL/I, IF could be the start of an IF-statement IF condition THEN or an assignment statement IF = expression. It's a bit more tricky for the parser as well as the programmer. Life is easier if words having special meanings are reserved. However, that doesn't mean that all special words /must/ be reserved (pragmatism beats purity). Sometimes the syntax makes it clear and unambiguous, so you can get away with not making it a reserved word. The word as in Python doesn't need to be reserved because the syntax precludes ambiguity, but it's the only such word in the language, so it's just tidier to make it reserved too. -- http://mail.python.org/mailman/listinfo/python-list I don't have a huge stake in this, but I wouldn't mind a change to allow anything proceeding a . or preceeding a ( to not be identified as a keyword. It is obvious to me a s a human reader that something.if is quite a bit different than just a bare if. And as far as parsing technology goes, isn't it supposed to go for the biggest match first? I would not be for allowing bare keywords to be used in the situations described above, but since we are so used to being able to being able to have say, myclass.dir() or myclass.len() without them overwriting the builtin functions, it makes sense to me to be able to define a myclass.as() or myclass.with() without overwriting the keywords. Though I know the semantics behind these two things are very different, the rules I go through when reading the code are very similar. The parser change might be a hassle, and it might not be worth it at all of course, but from a conceptual point of view it is simple. I mean, even now you can do class.__dict__[as]. so what happens here? if(some_condition()) : do_something(a) Yes, I know you don't need the parenthesis there in Python, but you still can use it. I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword usage. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, Dec 10, 2008 at 11:57 AM, Benjamin Kaplan [EMAIL PROTECTED] wrote: On Wed, Dec 10, 2008 at 12:22 PM, Patrick Mullen [EMAIL PROTECTED] wrote: I don't have a huge stake in this, but I wouldn't mind a change to allow anything proceeding a . or preceeding a ( to not be identified as a keyword. It is obvious to me a s a human reader that something.if is quite a bit different than just a bare if. And as far as parsing technology goes, isn't it supposed to go for the biggest match first? I would not be for allowing bare keywords to be used in the situations described above, but since we are so used to being able to being able to have say, myclass.dir() or myclass.len() without them overwriting the builtin functions, it makes sense to me to be able to define a myclass.as() or myclass.with() without overwriting the keywords. Though I know the semantics behind these two things are very different, the rules I go through when reading the code are very similar. The parser change might be a hassle, and it might not be worth it at all of course, but from a conceptual point of view it is simple. I mean, even now you can do class.__dict__[as]. so what happens here? if(some_condition()) : do_something(a) Yes, I know you don't need the parenthesis there in Python, but you still can use it. I guess I'm -1 for full PL/1 craziness, but +1 for qualified keyword usage. -- http://mail.python.org/mailman/listinfo/python-list Right, I now see how this scenario is tricky. It could maybe be in the form of def keyword|identifiercolon but that starts getting pretty complicated. Too tricky. Following the period on the other hand still makes sense to me. It makes sense in the nature of I wouldn't mind seeing this added, but I suppose it still might not make sense in the nature of We should do the work to make this a reality. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On 9 Des, 05:52, alex23 [EMAIL PROTECTED] wrote: From my perspective, it was less the original complaint and more the sudden jump to CPython is dead! The GIL sucks! Academic eggheads! that prompted the comparisons to trolling. To be fair to the complainant, before mentioning the GIL, he did initially get the usual trite fragments of the Zen of Python right back at him (simple is better than complex, special cases aren't special enough to break the rules), albeit not the whole thing in its overused, unabridged form. I think I'd go on a rant if presented with that rather than the accepted reason for the noted shortcomings of the language: CPython's parsing technology isn't sufficiently powerful parser technology as GvR himself says [1]. Paul [1] http://mail.python.org/pipermail/python-dev/2008-December/084023.html -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
2008/12/4 Chris Mellon [EMAIL PROTECTED]: Aside from the cultural indoctrination, though (and that may be a real and strong force when dealing with math software, and I don't want to discount it in general, just for purposes of this discussion) why is it more sensible to use x here instead of number or real or real_number or something else? Because long variable names in complicated math expressions lead to lines longer than 80 characters which hurts readability. You don't need to be a mathematician to see that. -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Tue, 09 Dec 2008 04:39:55 -0800, Paul Boddie wrote: To be fair to the complainant, before mentioning the GIL, he did initially get the usual trite fragments of the Zen of Python right back at him (simple is better than complex, special cases aren't special enough to break the rules), albeit not the whole thing in its overused, unabridged form. I think I'd go on a rant if presented with that rather than the accepted reason for the noted shortcomings of the language: CPython's parsing technology isn't sufficiently powerful parser technology as GvR himself says [1]. Paul [1] http://mail.python.org/pipermail/python-dev/2008-December/084023.html That is not what Guido said. What he actually said was: That's possible with sufficiently powerful parser technology, but that's not how the Python parser (and most parsers, in my experience) treat reserved words. In other words, with a more powerful parser, it would be POSSIBLE. But that doesn't mean that the only reason Python doesn't do what the OP wants is the lack of such a parser. To give an analogy: with sufficiently powerful automotive technology, we could all have cars capable of accelerating from 0 to 300mph in less than five seconds. (That's faster than the space shuttle accelerates, by the way.) The technology exists: drag racers have it. But the costs (financial and social) would be prohibitive, and so very few people have such cars, and those that do have restrictions on where and when they can use them. What Guido is saying is that even if he agreed with the OP he couldn't add that feature. He's not saying that he agrees with the OP. The Zen gives good reasons for believing that even if Python's parser was sufficiently powerful, he'd still consider the feature undesirable. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On 9 Des, 14:24, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: That is not what Guido said. What he actually said was: That's possible with sufficiently powerful parser technology, but that's not how the Python parser (and most parsers, in my experience) treat reserved words. I accept that many parsers are operating on predetermined tokens where keywords will already have been identified as such, regardless of their eventual syntactic context, by the time the parser gets to see them. What I wanted to point out was that other approaches are not exactly unheard of or particularly rare. Every now and again, the language gets extended and new keywords are sought in an excruciating process akin to a group writing exercise involving the existing keywords. A better parsing framework would alleviate these problems. [Car analogy cut] What Guido is saying is that even if he agreed with the OP he couldn't add that feature. He's not saying that he agrees with the OP. The Zen gives good reasons for believing that even if Python's parser was sufficiently powerful, he'd still consider the feature undesirable. Well, I think it's more interesting to explore the boundaries of what can be done, to debunk notions that such things aren't being done in the mainstream, and to examine whether they could benefit usability, than it is to defer to the Zen of Python as some kind of prescriptive, near-religious text at every turn. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Paul Boddie wrote: On 9 Des, 14:24, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: That is not what Guido said. What he actually said was: That's possible with sufficiently powerful parser technology, but that's not how the Python parser (and most parsers, in my experience) treat reserved words. I accept that many parsers are operating on predetermined tokens where keywords will already have been identified as such, regardless of their eventual syntactic context, by the time the parser gets to see them. What I wanted to point out was that other approaches are not exactly unheard of or particularly rare. Every now and again, the language gets extended and new keywords are sought in an excruciating process akin to a group writing exercise involving the existing keywords. A better parsing framework would alleviate these problems. [Car analogy cut] In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; See http://en.wikipedia.org/wiki/PL/I_(programming_language). What Guido is saying is that even if he agreed with the OP he couldn't add that feature. He's not saying that he agrees with the OP. The Zen gives good reasons for believing that even if Python's parser was sufficiently powerful, he'd still consider the feature undesirable. Well, I think it's more interesting to explore the boundaries of what can be done, to debunk notions that such things aren't being done in the mainstream, and to examine whether they could benefit usability, than it is to defer to the Zen of Python as some kind of prescriptive, near-religious text at every turn. Paul -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 9, 8:28 am, MRAB [EMAIL PROTECTED] wrote: snip In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; See http://en.wikipedia.org/wiki/PL/I_(programming_language). snip The following are semantically equivalent: I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. I wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. That is, 'certainly' doesn't change the meaning of your statement any. You wouldn't want it, but King George III didn't want the American Revolution. You wouldn't want it. What does that mean for me (the generic reader), and Python? What can I learn from that fact? -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 9, 9:28 am, MRAB [EMAIL PROTECTED] wrote: I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; Although I agree with the sentiment, you can write uncomprehensibly insane code in any language; Python already gives a lot of horsepower to run wild with metaclass magic, bytecode hacking, etc. The fact that you *can* write abominations as the above doesn't mean that you should; the OP's use case - using foo.as(int) - is pretty reasonable and readable. I believe the responsibility to not abuse the power of the language should be on the application programmer, not the language designer. George -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 9, 7:48 am, Paul Boddie [EMAIL PROTECTED] wrote: On 9 Des, 14:24, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: That is not what Guido said. What he actually said was: That's possible with sufficiently powerful parser technology, but that's not how the Python parser (and most parsers, in my experience) treat reserved words. I accept that many parsers are operating on predetermined tokens where keywords will already have been identified as such, regardless of their eventual syntactic context, by the time the parser gets to see them. What I wanted to point out was that other approaches are not exactly unheard of or particularly rare. Every now and again, the language gets extended and new keywords are sought in an excruciating process akin to a group writing exercise involving the existing keywords. A better parsing framework would alleviate these problems. And introduce an assload of new ones. What Guido is saying is that even if he agreed with the OP he couldn't add that feature. He's not saying that he agrees with the OP. The Zen gives good reasons for believing that even if Python's parser was sufficiently powerful, he'd still consider the feature undesirable. Well, I think it's more interesting to explore the boundaries of what can be done, to debunk notions that such things aren't being done in the mainstream, and to examine whether they could benefit usability, than it is to defer to the Zen of Python as some kind of prescriptive, near-religious text at every turn. As GvR mentioned in this thread, someone already did that with regard to parsing frameworks, and the result was PL/1. Seriously, that's not a good thing. To hell with the parser, what is everyone focusing on the parser in this thread? What about the human reader? Do you want the human reader to have to have all kinds of rules to memorize about when a symbol is an identifier and when it's a syntactic element? Do you want people to have to learn when to escape a symbol so that the parser treats it as an identifier instead of syntax? I'm not saying as alone was causing that--for once again Python showed what the best way to enter unpleasant waters is: with a lot of restraint--but a better parsing framework that eliminated keywords would cause lots of confusion. And finally: it's just plain bad style to use a syntactic element as an identifier, even when allowed. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Tue, Dec 9, 2008 at 6:39 AM, Paul Boddie [EMAIL PROTECTED] wrote: On 9 Des, 05:52, alex23 [EMAIL PROTECTED] wrote: From my perspective, it was less the original complaint and more the sudden jump to CPython is dead! The GIL sucks! Academic eggheads! that prompted the comparisons to trolling. To be fair to the complainant, before mentioning the GIL, he did initially get the usual trite fragments of the Zen of Python right back at him (simple is better than complex, special cases aren't special enough to break the rules), albeit not the whole thing in its overused, unabridged form. I think I'd go on a rant if presented with that rather than the accepted reason for the noted shortcomings of the language: CPython's parsing technology isn't sufficiently powerful parser technology as GvR himself says [1]. Paul So hold up a second. I'm out of line for calling someone on making a trollish post that's not relevant to the topic, and for being pretty late to the party even with the part that *was* on topic, and for (even in the original post) going the ad-hominem route by not so subtly implying that Python is an ivory tower language that's not good enough for people with real problems - a clearly false statement by any standards, and doubly offensive from someone who *is* using it for real problems and who himself is a less than shining example of responsible software management, but the OPs lapse into ranting in response to trite but accurate answers to a question he could have answered for himself, in detail, had he bothered to read the threads from the time when the issue actually matter is a reasonable response that we should support and validate? Sometimes you're not a crusader for thinking differently and change by confrontation and speaking truth to power. Sometimes you're just an asshole. For clarification: The OPs original complaint is legitimate, if dated and partially his own fault. His phrasing of the problem, the tone and content of his email, and his lapse into flaming when he wasn't immediately hailed as a herald of sanity is not legitimate. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Aaron Brady wrote: On Dec 9, 8:28 am, MRAB [EMAIL PROTECTED] wrote: snip In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; See http://en.wikipedia.org/wiki/PL/I_(programming_language). snip The following are semantically equivalent: I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. I wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. That is, 'certainly' doesn't change the meaning of your statement any. You wouldn't want it, but King George III didn't want the American Revolution. It's called emphasis. You wouldn't want it. What does that mean for me (the generic reader), and Python? What can I learn from that fact? -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Carl Banks wrote: [ ... ] Do you want the human reader to have to have all kinds of rules to memorize about when a symbol is an identifier and when it's a syntactic element? Do you want people to have to learn when to escape a symbol so that the parser treats it as an identifier instead of syntax? Then again, Python programmers should be used to namespaces, and it shouldn't bother people that `open` means one thing, and `image.open` means something very different -- if you've imported image. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Tue, 09 Dec 2008 08:30:26 -0800, Aaron Brady wrote: The following are semantically equivalent: I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. I wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. Certainly adds emphasis. You don't just mildly not want something like PL/I, but you really don't want it, so much so that you're amazed that anyone might have thought you did. The English language is very un-Pythonic. It especially breaks Explicit is better than implicit -- words have many implied connotations which are not necessarily found in dictionaries. For example, a wise guy and a wise man are not the same thing, even though a guy and a man are the same. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Tue, 09 Dec 2008 05:48:29 -0800, Paul Boddie wrote: Well, I think it's more interesting to explore the boundaries of what can be done, to debunk notions that such things aren't being done in the mainstream, and to examine whether they could benefit usability, than it is to defer to the Zen of Python as some kind of prescriptive, near-religious text at every turn. Go right ahead. Write your experimental language, and if people like it, they'll use it. That's what Guido did, all those years ago. But don't turn Python into a hodgepodge of features that most people consider misfeatures. The Zen certainly is prescriptive, but it's not near-religious in any sense. It's a distillation of probably hundreds of man-years of programming experience from people like Guido and Tim Peters into a small number of heuristics about the sorts of design decisions which have been proven to be successful in the past. I think it is childish to reject the Zen just because it's the Zen. Good advice doesn't cease to be good advice just because people tell you it's good advice, even if some people are awfully strident about it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 9, 12:40 pm, MRAB [EMAIL PROTECTED] wrote: Aaron Brady wrote: On Dec 9, 8:28 am, MRAB [EMAIL PROTECTED] wrote: snip In some languages (I think Delphi is one of them - it's been a while!) some words which would normally be identifiers have a special meaning in certain contexts, but the syntax precludes any ambiguity, and not in a difficult way. as in Python was one of those. I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers, so you could have code like: IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF; Seehttp://en.wikipedia.org/wiki/PL/I_(programming_language). snip That is, 'certainly' doesn't change the meaning of your statement any. You wouldn't want it, but King George III didn't want the American Revolution. It's called emphasis. I just take you to have meant, then, +1 on excluding keywords from identifiers. You said it the long way though, so I thought I missed something deeper, that didn't come across. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 9, 4:53 pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Tue, 09 Dec 2008 08:30:26 -0800, Aaron Brady wrote: The following are semantically equivalent: I certainly wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. I wouldn't want something like PL/I, where IF, THEN and ELSE could be identifiers. Certainly adds emphasis. You don't just mildly not want something like PL/I, but you really don't want it, so much so that you're amazed that anyone might have thought you did. I see. He was expressing amazement too. This is distinct from a similar case, -1 on including it, but it has some advantages, and could be useful for other purposes. He thinks it's a bad idea all around, not just ill-suited to Python. The English language is very un-Pythonic. It especially breaks Explicit is better than implicit -- words have many implied connotations which are not necessarily found in dictionaries. For example, a wise guy and a wise man are not the same thing, even though a guy and a man are the same. I can't attest to many other languages, but the same might hold true. It's the speakers, not the language. English also breaks 'Errors should never pass silently', though more so in large I have the conch gatherings, and less so in smaller numbers. If I end up at the wrong restaurant for dinner, that's the equivalent (analogue) of reading from uninitialized memory, or other silently passed errors. 'Special cases aren't special enough to break the rules.' Italian breaks this one--- 700 irregular verbs! But the Esperanto community is growing... heh heh. English spelling is bad too: if 'i' before 'e' and not after 'c': ...' It's not a fair fight though, between English and Python. There's no 'final say', that is, unifying vision, about what's legal in English. People will just talk. If everyone drops their articles tomorrow, English no longer has them. Perhaps you could compare Python to an audience to English with only one member. I guess I take 'complex' and 'nested' to be about the same. Back to topic, the 'eth' sound might be ugly to some humans. But that doesn't mean it's ugly to English speakers, let alone useless. I guess some people think the disjunction of 'useful' and 'ugly' is nearly empty. I think one of the things the Zen has going for it is its authors were (are) programmers-- they taste their own medicine. In naturally occurring large religions, the priests aren't peasants very often... though sometimes the prophets are. You could compare the Zen to 'folk wisdom' per se, rather than a religion (though the latter proclaims itself the former too often). Just because you defer to something, doesn't mean it's a religion. But if the content has drifted so far that Peters and van Rossum no longer follow it, it's a bad sign. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 5:39 pm, Chris Mellon [EMAIL PROTECTED] wrote: Honestly, based on the content and tenor of this post I think this is Yet Another Python Troll So original: disagreeable criticism is trolling. A few points... Short keywords are more likely to collide with short variable and attribute names, and while we should all use descriptive names for things, the complainant does seem to have found a reasonable application of a short name; when new short keywords are introduced, conflicts with such applications are inevitable, and that's exactly what has happened here. Anyone who has used any library or framework which combines another domain or technology with Python has probably seen names with trailing underscores; I believe PyQt employs exec_ instead of exec in various places, for example. Choosing some other name which needs no underscore can work against the beginner if they are referring to generic documentation. My message on python-dev about parsers and keywords noted that some languages manage to achieve what the complainant wants, more or less. SQL implementations, for example, can often deal with keywords if they are qualified, and it is even possible to double-quote keywords and use them as identifiers: create table create ( select varchar ); select select from create; select create.select from create; (This from a PostgreSQL 8.2 session.) [...] If you suppressed or ignored the deprecation warning that all your code has been generating for at least 2 years it's pretty damn ballsy to come here and tell everyone how *Python* is doing something wrong. Maybe the complainant realises that he has no say in this matter and that he has to raise it in this fashion as a last resort. I've only skimmed this thread, but if the complainant is still using 2.4 (like a number of people) he won't have seen such a warning (although maybe he admits seeing it somewhere amongst the pile of how dare you criticise?! messages), and now he sees that he's running out of road. What I can say is that it certainly does take balls to see matters from the other guy's perspective instead of calling someone names for pointing something out. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, 2008-12-03 at 21:42 -0800, Warren DeLano wrote: Anyway, it seems obvious that the right decision for our customers (or more importantly, for their countless lines of autogenerated-Python log, state, and code files from the past decade) is to stick with C/Python 2.5.x for the time being and plan to make the jump to a threads-capable and hopefully backwards-compatible Python implementation as soon as possible (IronPython perhaps?). That seems like a sensible path around the breakage and enduring limitations of C/Python 2.6 or 3. All that broken code does sound like a hassle. However, I think the workaround would be a fairly simple refactor: 1) make 'as_type' (or some other equivalent name like 'as_') a synonym for 'as': class Foo(object): ... def as(self): ... pass ... as_type = as 2) Change all references in Foo in your code base to use 'as_type'. 3) Extract class Foo to a separate file (_as_import_file.py), and replace it in the original file with: from _as_import_file import Foo (Note that no other files should import directly from _as_import_file.py) 4) Now write a second file (_as_import_file_2_6.py), which defines defines Foo without as, just using as_type: class Foo(object): ... def as_type(self): ... pass 5) Change your import to select the appropriate import: try: ... from _as_import_file import Foo ... except SyntaxError: ... from _as_import_file_2_6 import Foo 6) Now your code base is fully functional with both 2.5 and 2.6. Everything functions exactly the same as it did before on 2.5, except now Foo.as_type() (or Foo.as_()) works as a synonym for Foo.as(). Tell your customers that they can upgrade to 2.6 if they update their own uses of as_type. In the meantime, their code is still functional on 2.5. By extracting Foo to _as_import_file, you only have to maintain one class in parallel. Better yet, have _as_import_file.Foo subclass _as_import_file_2_6.Foo, like so: _as_import_file_2_6.py class Foo(object): ... def as_type(self,type): ... pass _as_import_file.py import _as_import_file_2_6 class Foo(_as_import_file.Foo): ... as = _as_import_file.Foo.as_type That three line file, along with the four line conditional import are all you need for each import, and best of all, it's completely hidden from your users, until they want to migrate to python 2.6, and then all they have to do is change all references to Foo.as to point to Foo.as_type. But by observing step 1 above, they can do that at leisure, without fearing to break their code. I hope that's a helpful workaround for you and your users. Cheers, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 9, 5:21 am, Paul Boddie [EMAIL PROTECTED] wrote: What I can say is that it certainly does take balls to see matters from the other guy's perspective instead of calling someone names for pointing something out. From my perspective, it was less the original complaint and more the sudden jump to CPython is dead! The GIL sucks! Academic eggheads! that prompted the comparisons to trolling. Especially in this case, where Chris was responding to the follow-up rant rather than the initial complaint. So I think to a certain degree the troll-typing reactions are understandable :) -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
En Mon, 08 Dec 2008 18:07:22 -0200, J. Cliff Dyer [EMAIL PROTECTED] escribió: On Wed, 2008-12-03 at 21:42 -0800, Warren DeLano wrote: Anyway, it seems obvious that the right decision for our customers (or more importantly, for their countless lines of autogenerated-Python log, state, and code files from the past decade) is to stick with C/Python 2.5.x for the time being and plan to make the jump to a All that broken code does sound like a hassle. However, I think the workaround would be a fairly simple refactor: 1) make 'as_type' (or some other equivalent name like 'as_') a synonym for 'as': Another workaround was posted last Wednesday by Matimus in message http://groups.google.com/group/comp.lang.python/msg/128a2cec74a96d3d Both seem like a reasonable solution. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 9:35 pm, Carl Banks [EMAIL PROTECTED] wrote: On Dec 6, 8:17 pm, Steven D'Aprano [EMAIL PROTECTED] I don't like cast, because a cast is an instruction to the compiler to treat data as some type other than what it was defined as. It doesn't create a new piece of data. (At least in C-like languages.) Actually, C-like languages do exactly that. (float)i doesn't take the bits of int i and treat them as if they were a float, it creates new data in the appropriate data type that matches the value of i semantically, which would have a very different bit pattern. '(float) i' does what he said. int i; float f= ( (float) i ); f= 1; printf( %x %f\n, i, f ); /Output: 3f80 1.00 Sorry for the tangent. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 2:29 pm, Guido van Rossum [EMAIL PROTECTED] wrote: snip So, assuming I now wish to propose a corrective PEP to remedy this situation for Python 3.1 and beyond, what is the best way to get started on such a proposal? Don't bother writing a PEP to make 'as' available as an attribute again. It has no chance of being accepted. Instead, think of a different word you could use. You could use the Latin 'qua' or the Spanish 'como', for example. qua: -dictionary.com –adverb as; as being; in the character or capacity of: The work of art qua art can be judged by aesthetic criteria only. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 8:16�am, Wolfgang Strobl [EMAIL PROTECTED] wrote: Dennis Lee Bieber [EMAIL PROTECTED]: On 05 Dec 2008 05:21:25 GMT, Steven D'Aprano [EMAIL PROTECTED] declaimed the following in comp.lang.python: On Thu, 04 Dec 2008 08:44:19 -0800, Matimus wrote: The point was that there is that new releases don't _break_ anything. But that's clearly not true, because the OP is pointing out that the new release from 2.5 to 2.6 *does* break his code. � �One now has to ask what break really meant... For this example, the change did not break Python SYNTAX -- just a complaint about using what is now a reserved word as an object name. Of course it does: C:\Python26python Python 2.6 (r26:66721, Oct �2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win 32 Type help, copyright, credits or license for more information. as=2 � File stdin, line 1 � � as=2 � � �^ SyntaxError: invalid syntax I disagree. Broken is something you can't work around. In this case, simply saying as_=2 works fine. A better example of broken was when the gmpy module wouldn't solve a certain linear congruence problem because the problem was not invertible. But mathematically, solving a linear congruence does NOT depend on the problem being invertible. It was the ALGORITHM that depended on the problem being invertible and there was nothing the user could do to make the algorithm behave properly. The algorithm had to be altered to fix the special case of a solvable linear congruence not being invertible. Making a former syntactically valid �two letter name a reserved word in 2.6 was a mistake, IMHO. I think you're in the minority there. What's next? What about making i,j,k, x and y reserved words in 2.7? =:-/ Yeah, right. That'll happen. You ought to be more concerned about real problems. -- Thank you for observing all safety precautions -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Mensanator wrote: On Dec 6, 8:16�am, Wolfgang Strobl [EMAIL PROTECTED] wrote: Dennis Lee Bieber [EMAIL PROTECTED]: On 05 Dec 2008 05:21:25 GMT, Steven D'Aprano [EMAIL PROTECTED] declaimed the following in comp.lang.python: On Thu, 04 Dec 2008 08:44:19 -0800, Matimus wrote: The point was that there is that new releases don't _break_ anything. But that's clearly not true, because the OP is pointing out that the new release from 2.5 to 2.6 *does* break his code. � �One now has to ask what break really meant... For this example, the change did not break Python SYNTAX -- just a complaint about using what is now a reserved word as an object name. Of course it does: C:\Python26python Python 2.6 (r26:66721, Oct �2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win 32 Type help, copyright, credits or license for more information. as=2 � File stdin, line 1 � � as=2 � � �^ SyntaxError: invalid syntax I disagree. Broken is something you can't work around. In this case, simply saying as_=2 works fine. A better example of broken was when the gmpy module wouldn't solve a certain linear congruence problem because the problem was not invertible. But mathematically, solving a linear congruence does NOT depend on the problem being invertible. It was the ALGORITHM that depended on the problem being invertible and there was nothing the user could do to make the algorithm behave properly. The algorithm had to be altered to fix the special case of a solvable linear congruence not being invertible. Making a former syntactically valid �two letter name a reserved word in 2.6 was a mistake, IMHO. I think you're in the minority there. I think that its special use is clear from the syntax, so IMHO it could've been left for Python 3, but I'm not going to lose any sleep over it. What's next? What about making i,j,k, x and y reserved words in 2.7? =:-/ Yeah, right. That'll happen. You ought to be more concerned about real problems. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Date: Fri, 05 Dec 2008 22:22:38 -0800 From: Dennis Lee Bieber [EMAIL PROTECTED] Subject: Re: as keyword woes To: python-list@python.org Message-ID: [EMAIL PROTECTED] I'm still in the dark as to what type of data could even inspire the use of as as an object name... A collection of a objects? In which case, what are the as? G Please let me clarify. It is not as as a standalone object that we specifically miss in 2.6/3, but rather, the ability to use .as used as a method or attribute name. In other words we have lost the ability to refer to as as the generalized OOP-compliant/syntax-independent method name for casting: new_object = old_object.as(class_hint) # For example: float_obj = int_obj.as(float) # or float_obj = int_obj.as(float_class) # as opposed to something like float_obj = int_obj.asFloat() # which requires a separate method for each cast, or float_obj = (float)int_obj # which required syntax-dependent casting [language-based rather than object-based]. Of course, use of explicit casting syntax (float) is fine if you're restricting yourself to Python and other languages which support casting, but that solution is unavailable inside of a pure OOP message-passing paradigm where object.method(argument) invocations are all you have to work with. Please note that use of object.asClassname(...) is a ubiqitous convention for casting objects to specific classes (seen in ObjectiveC, Java, SmallTalk, etc.). There, I assert that 'object.as(class_reference)' is the simplest and most elegant generalization of this widely-used convention. Indeed, it is the only obvious concise answer, if you are limited to using methods for casting. Although there are other valid domain-specific uses for as as either a local variable or attribute names (e.g. systematic naming: as, bs, cs), those aren't nearly as important compared to as being available as the name of a generalized casting method -- one that is now strictly denied to users of Python 2.6 and 3. As someone somewhat knowledgable of how parsers work, I do not understand why a method/attribute name object_name.as(...) must necessarily conflict with a standalone keyword as . It seems to me that it should be possible to unambiguously separate the two without ambiguity or undue complication of the parser. So, assuming I now wish to propose a corrective PEP to remedy this situation for Python 3.1 and beyond, what is the best way to get started on such a proposal? Cheers, Warren -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
In my opinion, this thread is a crock of balony. Python *occasionally* adds keywords after giving a warning or requiring a future import in previous versions. In 2.2, one had to 'from __future__ import generators' to make a generator because doing so required the new 'yield' keyword. In 2.3, yield became a keyword without the import. In 2.5, one had to 'from __future__ import with_statement' to make a 'with' statement. In 2.6, with because a keyword without the import. And no one seems to have noticed. No 'with keyword woes. In 2.6, 'as' also because a full-time keyword after several releases of being an anomalous part-time contextual keyword. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 1:38 pm, Warren DeLano [EMAIL PROTECTED] wrote: There, I assert that 'object.as(class_reference)' is the simplest and most elegant generalization of this widely-used convention. Indeed, it is the only obvious concise answer, if you are limited to using methods for casting. I don't agree with your assertion. object.as_type(class_reference) object.cast(class_reference) These are both concise and obvious. As someone somewhat knowledgable of how parsers work, I do not understand why a method/attribute name object_name.as(...) must necessarily conflict with a standalone keyword as . It seems to me that it should be possible to unambiguously separate the two without ambiguity or undue complication of the parser. It's possible, and they've been doing it for years, and they could have continued doing it if they wanted to. You'll notice that nowhere the Python grammar can two identifiers be separated by whitespace. So if you have two identifiers separated by whitespace, and the second one is as, you know it has to be keyword as. Well, they made it a keyword anyway. It was never a question of whether they could do it. So, assuming I now wish to propose a corrective PEP to remedy this situation for Python 3.1 and beyond, what is the best way to get started on such a proposal? I think you'd be wasting your time, but the general procedure is outlined in PEP 1. Basically, you write a pre-PEP (aka PEP XXX) according to the guidelines in PEP 1, which you would post here and request comments on it. Then, if you can muster some support for it, you would send it to PEP maintainer (the email is listed somewhere on the PEPs page, dig for it), and get a number assigned, upon which time Guido van Rossum will read it and any comments in python-dev, and make a pronouncement of some sort. If you write a PEP, I advise you to try to sound less whiny and than you have in this thread. Saying object.as(class_reference) is highly convenient because it mirrors textually the Java convention of object.asFloat will go over a lot better than object.as (class_reference) is the only obvious concise answer. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 7, 2:38 am, Warren DeLano [EMAIL PROTECTED] wrote: Date: Fri, 05 Dec 2008 22:22:38 -0800 From: Dennis Lee Bieber [EMAIL PROTECTED] Subject: Re: as keyword woes To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] I'm still in the dark as to what type of data could even inspire the use of as as an object name... A collection of a objects? In which case, what are the as? G Please let me clarify. It is not as as a standalone object that we specifically miss in 2.6/3, but rather, the ability to use .as used as a method or attribute name. In other words we have lost the ability to refer to as as the generalized OOP-compliant/syntax-independent method name for casting: new_object = old_object.as(class_hint) # For example: float_obj = int_obj.as(float) # or float_obj = int_obj.as(float_class) # as opposed to something like float_obj = int_obj.asFloat() # which requires a separate method for each cast, or float_obj = (float)int_obj # which required syntax-dependent casting [language-based rather than object-based]. Of course, use of explicit casting syntax (float) is fine if you're restricting yourself to Python and other languages which support casting, but that solution is unavailable inside of a pure OOP message-passing paradigm where object.method(argument) invocations are all you have to work with. Please note that use of object.asClassname(...) is a ubiqitous convention for casting objects to specific classes (seen in ObjectiveC, Java, SmallTalk, etc.). There, I assert that 'object.as(class_reference)' is the simplest and most elegant generalization of this widely-used convention. Indeed, it is the only obvious concise answer, if you are limited to using methods for casting. Although there are other valid domain-specific uses for as as either a local variable or attribute names (e.g. systematic naming: as, bs, cs), those aren't nearly as important compared to as being available as the name of a generalized casting method -- one that is now strictly denied to users of Python 2.6 and 3. As someone somewhat knowledgable of how parsers work, I do not understand why a method/attribute name object_name.as(...) must necessarily conflict with a standalone keyword as . It seems to me that it should be possible to unambiguously separate the two without ambiguity or undue complication of the parser. So, assuming I now wish to propose a corrective PEP to remedy this situation for Python 3.1 and beyond, what is the best way to get started on such a proposal? Cheers, Warren And let things like: filelike.print('lpt') # python 2.6 zipper.with('7z') failure.try(alternative) executecodeobject.if(True) onfailure.break() ? -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Warren DeLano wrote: As someone somewhat knowledgable of how parsers work, I do not understand why a method/attribute name object_name.as(...) must necessarily conflict with a standalone keyword as . It seems to me that it should be possible to unambiguously separate the two without ambiguity or undue complication of the parser. The lexer, which preceeds the parser, has separate KEYWORD and IDENTIFIER categories. For example, 'if a ...' is lexed as (KEYWORD, 'if'), (IDENTIFIER, 'a'), ... . Leaving 'as' as an identifier identified by the parser as a contextual keyword in import statements was a kludge. When 'as' was reused in with expr as target in 2.5 (with __future__ import), it was planned and announced that *both* 'with' and 'as' would become full-time keywords in 2.6, just as 'yield' did in 2.3 after its introduction (with required __future__) in 2.2. Making 'yield' a keyword of course impacted people who used the word in financial calculations, but they adjusted. So, assuming I now wish to propose a corrective PEP Working with people trying to improve threading would be more productive. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 2:09�pm, Wolfgang Strobl [EMAIL PROTECTED] wrote: Mensanator [EMAIL PROTECTED]: On Dec 6, 8:16?am, Wolfgang Strobl [EMAIL PROTECTED] wrote: Dennis Lee Bieber [EMAIL PROTECTED]: On 05 Dec 2008 05:21:25 GMT, Steven D'Aprano [EMAIL PROTECTED] declaimed the following in comp.lang.python: On Thu, 04 Dec 2008 08:44:19 -0800, Matimus wrote: The point was that there is that new releases don't _break_ anything. But that's clearly not true, because the OP is pointing out that the new release from 2.5 to 2.6 *does* break his code. ? ?One now has to ask what break really meant... For this example, the change did not break Python SYNTAX -- just a complaint about using what is now a reserved word as an object name. Of course it does: C:\Python26python Python 2.6 (r26:66721, Oct ?2 2008, 11:35:03) [MSC v.1500 32 bit (Intel)] on win 32 Type help, copyright, credits or license for more information. as=2 ? File stdin, line 1 ? ? as=2 ? ? ?^ SyntaxError: invalid syntax I disagree. Broken is something you can't work around. Well, that language change _did_ break the OPs code, and he already explained why it isn't as simple to work around as you obviously happen to believe. It was extremely simple for me to fix the sympy module where I noticed it. I'm not saying it wasn't a problem, I'm saying it wasn't BROKEN. And no, I couldn't use sympy after the fix because apparently there is some change the way 2.6 hashes which truly breaks the sympy code, so no using sympy with 2.6 until a corrected version is released. And the real problem is that the latest version was released without ever testing it under 2.6. Hopefully, that won't happen again. � Calling it not a SYNTAX error is not only mistaken, it's weaseling around the problem too. It's not weaseling around the problem, it's rating the seriousness of the problem. Right now if I need sympy, I HAVE to use 2.5, if I need itertools.permutations I HAVE to use 2.6. But I canot use both in the same program which is a tad more serious than having to rename a variable I had business using in the first place. In this case, simply saying as_=2 works fine. Certainly not, for example when that name is already used outside your control. In addition, you'll have to find all places, where the now syntactically illegal name is or might be used. This can get arbitrarily hard in generated �or foreign code. The difficulty of fixing it isn't the issue, it's whether it can be fixed at all. A better example of broken was when the gmpy module wouldn't solve a certain linear congruence problem because the problem was not invertible. What does that have to to with anything? It's an example of what it means to be BROKEN, and yes, nothing at all to do with SYNTAX. We're disussing a language change on the syntax level which breaks existing legal code, not how a numerical library behaves for borderline cases. And yet, you don't consider this a case of weasel words. Strange. [...] Making a former syntactically valid ?two letter name a reserved word in 2.6 was a mistake, IMHO. I think you're in the minority there. Perhaps. Does that matter? Yeah, if you think it will be resolved in your favor. What's next? What about making i,j,k, x and y reserved words in 2.7? =:-/ Yeah, right. That'll happen. Certainly not. �On the other hand, I was quite flabbergasted by the change in question, likewise. Wasn't that something �reserved for 3.0: breaking code mercilessly? � Mercilessly? If there were no deprecation warnings, you might have a case there. You act as if the failure to display such warnings was deliberate, but that was due to a BUG, not merciless behaviour on the part of the developers. What is 3.0 good for, when we have to bear such breakage in a minor release, already? You're making a mountain out of a molehill. You ought to be more concerned about real problems. It is a real problem for the OP. Who gave him permission to use 2.6? Is 2.5 suddenly unavailable? Assholes like Microsoft pull stunts like that, but Python.org doesn't. If it's his code, he can easily fix it. If it's someone else's code, he should be using a version guaranteed to work in 2.6. -- Thank you for observing all safety precautions -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Sat, 06 Dec 2008 14:36:07 -0800, Mensanator wrote: It was extremely simple for me to fix the sympy module where I noticed it. I'm not saying it wasn't a problem, I'm saying it wasn't BROKEN. If it wasn't broken, why did you need to fix it? Broken means not working, not unfixable. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 6:25�pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Sat, 06 Dec 2008 14:36:07 -0800, Mensanator wrote: It was extremely simple for me to fix the sympy module where I noticed it. I'm not saying it wasn't a problem, I'm saying it wasn't BROKEN. If it wasn't broken, why did you need to fix it? If my tire is flat, I have to fix it. But it may just need air, in which case it's not broken. Broken means not working, not unfixable. So, you're saying that Python is broken and will remain so forever, since as will remain a keyword? Are you advocating that we all switch to Ruby? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Sat, 06 Dec 2008 18:09:07 -0800, Mensanator wrote: On Dec 6, 6:25�pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Sat, 06 Dec 2008 14:36:07 -0800, Mensanator wrote: It was extremely simple for me to fix the sympy module where I noticed it. I'm not saying it wasn't a problem, I'm saying it wasn't BROKEN. If it wasn't broken, why did you need to fix it? If my tire is flat, I have to fix it. But it may just need air, in which case it's not broken. In which case it doesn't need *fixing*, it needs *refilling*. A flat tire isn't necessarily broken. It is broken if it has a puncture or a slow leak or has been ripped to shreds, but not if somebody merely let the air out. Air comes out if you open the value is within standard operating parameters and the tire is therefore working correctly. Broken means not working, not unfixable. So, you're saying that Python is broken and will remain so forever, since as will remain a keyword? I don't think that having as be a keyword is broken. I think the OP's code is broken for Python 2.6 or better, and it will remain broken forever unless he fixes it or chooses to stay with 2.5. Are you advocating that we all switch to Ruby? Why do you think that? Do you imagine that Ruby has no features which are inconvenient to users, or backwards incompatibilities, or warts, or that it is impossible to write broken Ruby code? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 8:17 pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Sun, 07 Dec 2008 11:27:56 +1000, Nick Coghlan wrote: Warren DeLano wrote: In other words we have lost the ability to refer to as as the generalized OOP-compliant/syntax-independent method name for casting: Other possible spellings: # Use the normal Python idiom for avoiding keyword clashes # and append a trailing underscore new_object = old_object.as_(class_hint) float_obj = int_obj.as_(float) float_obj = int_obj.as_(float_class) # Use a different word (such as, oh, cast perhaps?) new_object = old_object.cast(class_hint) float_obj = int_obj.cast(float) float_obj = int_obj.cast(float_class) I don't like cast, because a cast is an instruction to the compiler to treat data as some type other than what it was defined as. It doesn't create a new piece of data. (At least in C-like languages.) Actually, C-like languages do exactly that. (float)i doesn't take the bits of int i and treat them as if they were a float, it creates new data in the appropriate data type that matches the value of i semantically, which would have a very different bit pattern. Pointer-to-int and pointer-to-pointer typecasts are really the only ones that tend to preserve the bits of the data (which, since they are the most common kinds of typecast, has misled some people to think that typecasts in C are all about preserving bits). However, in general typecasts preserve the semantic value of the original data. That's exactly what these methods would be doing, changing the type while preserving the semantic value as much as possble, so cast is a perfectly appropriate name for it. (BTW, in C++, even pointer-to-pointer static casts don't always preserve the bits.) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Date: Sat, 6 Dec 2008 12:13:16 -0800 (PST) From: Carl Banks [EMAIL PROTECTED] Subject: Re: as keyword woes To: python-list@python.org Message-ID: (snip) If you write a PEP, I advise you to try to sound less whiny and than you have in this thread. (snip) Ehem, well, such comments notwithstanding, I thank everyone who responded to my latest post on this topic for taking my inquiry seriously, and for providing cogent, focused, well-reasoned feedback while not resorting to name-calling, to false accusations on top of baseless assumptions, or to explicit personal attacks on my competence, sincerity, experience, credibility, or form. To you especially, I am grateful for your input for your years of service to the community and to the noble ideals you embody in the Python project. May the rest of us (not just myself) be ashamed of our lesser conduct and learn from you exemplary performance. So to summarize, having assimilated all responses over the past several days (python-list as well as python-dev, for the newcomers), I now accept the following as self-evident: - as, as a Python keyword, is a here to stay: Love it or leave it. - Likewise ditto for the GIL: if you truly need Python concurrency within a single process, then use a Python implementation other than CPython. Season's greetings to all! Peace. Cheers, Warren -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 6, 9:09�pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Sat, 06 Dec 2008 18:09:07 -0800, Mensanator wrote: On Dec 6, 6:25 pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Sat, 06 Dec 2008 14:36:07 -0800, Mensanator wrote: It was extremely simple for me to fix the sympy module where I noticed it. I'm not saying it wasn't a problem, I'm saying it wasn't BROKEN. If it wasn't broken, why did you need to fix it? If my tire is flat, I have to fix it. But it may just need air, in which case it's not broken. In which case it doesn't need *fixing*, The state of the tire being flat has to be fixed, but not necessarily the tire. it needs *refilling*. A flat tire isn't necessarily broken. It is broken if it has a puncture or a slow leak or has been ripped to shreds, but not if somebody merely let the air out. Air comes out if you open the value is within standard operating parameters and the tire is therefore working correctly. Just as as producing a syntax error is working correctly. Broken means not working, not unfixable. So, you're saying that Python is broken and will remain so forever, since as will remain a keyword? I don't think that having as be a keyword is broken. But WS does and you appear to be taking his side. I think the OP's code is broken for Python 2.6 or better, So do I. Why are you arguing then? Simply to be pedantic about the meaning of broken? and it will remain broken forever unless he fixes it or chooses to stay with 2.5. Are you advocating that we all switch to Ruby? Why do you think that? Because seem to be agreeing that the problem is with Python. If that's not what you meant, it's not coming across that way. Do you imagine that Ruby has no features which are inconvenient to users, or backwards incompatibilities, or warts, or that it is impossible to write broken Ruby code? Who knows what you believe if you're agrreing that Python is permanently broken? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On 04 Dec 2008 22:29:41 GMT Steven D'Aprano [EMAIL PROTECTED] wrote: Thank goodness we don't have to program in verbose, explicit English! Then you'll HATE Inform 7: http://en.wikipedia.org/wiki/Inform_7#Example_game_2 :) /W -- My real email address is constructed by swapping the domain with the recipient (local part). -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
I don't know how you infer any of those from what I said, nor from the process of introducing features in Python. None of what you say there rings at all true with anything I've experienced in Python's core or the attitudes surrounding development if the language; indeed, quite the opposite. That has been my experience as well, which is why this particular action seems surprising and out of character. Speaking of irony, you're complaining about namespace conflicts with a -two character identifier- you've chosen. Here's a hint: choose better names. Hey, come on now -- developers working on top of an existing language bear nowhere near the responsibility as the language implementation maintainers. Also, note that the fields of math and science are filled with short identifiers with well-defined meanings -- brevity doesn't mean ambiguous within a given application domain! But regardless, our scripts use as in the same way as Python -- to change the effective appearance of an object, albeit in a representational rather than naming space. So if we're wrong in our choice, then so is Python. In addition, note that my choice of a concise method identifier affects only my users. Python's introduction of a new keyword affects the entire Python world code base, so perhaps you should be directing your choose better names criticism in another direction? To match your honesty, I'm somewhat tired with the trend of some people to hit -one- issue with Python and suddenly lash out like children over all the same old tired crap. Have you even looked at multiprocessing? Have you contributed to any projects working on GIL- less implementations? Or are you just regurgitating the same bullet points we've heard time and time again? Multiprocessing solves some problems, but it is unsuitable for high-frequency handoffs of large (in memory) objects between many independent threads/processes -- the HPC object/data flow parallelization model in a nutshell. Furthermore, not every coder has the compsci chops to work on language VM implementations (my PhD involved programming DNA and directing evolution in a test tube, not parse trees and state machines). But that isn't to say I didn't try: at one point I even sketched out a possible TLS-based GIL workaround for handling the issue without breaking the existing C/API. It was of course shunned by those who knew better...for performance reasons IIRC. For chrissake, if you cannot do ANYTHING but BITCH about a change, then you've no damn right to consider yourself a programmer. Real programmers find solutions, not excuses. Though I have certainly bitched about the threading issue multiple times on mailing lists including baypiggies and python-dev, bitching is not the only thing I've done. Having come to grips with my own coding limitations, I also offered to contribute financial resources from my own Python-enhanced business in support of GIL-removal -- before Python 3.0 was finalized. Unfortunately, no one responded to my offer. Even today, I am indirectly proposing the solution of as not being a reserved keyword since it has worked just fine for years without it. Yes that's late, but I didn't see this particular trainwreck coming (since it is not actually our current code which breaks, but rather, quantities of code created years ago but which must still run with fidelity into the far off future). Installing a Python macro preprocessor is another after-the-fact possible solution which may bear further investigation... Also today, I am proposing a pragmatic general solution for projects like ours in addressing both the 2.6/3.0 compatibility and threading situations. Specifically: deliberate migration away from C/Python and on to alternate VMs which happen to support Python syntax. Obviously none of my past efforts yielded fruit -- but it is wrong and unfair of you to assume and accuse me of not trying to come up with solutions. Solutions are virtually the entire game! And if so, then thank you all for so many wonderful years of effort and participation! You're welcome. Don't let the door hit you on the ass on your way out. But who's leaving who exactly? Surely a language as beautiful as Python will easily transcend the limitations of its flagship implementation (if or to the extent that such an implementation cannot keep pace with the times). That's all well and good -- it may even end up being the next great leap forward for the language. I believe Guido has even said as much himself. Warren -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
alex23 wrote: On Dec 4, 3:42 pm, Warren DeLano [EMAIL PROTECTED] wrote: So you prefer broken code to broken rules, eh? Your customers must love that! This is exactly the kind of ivory-tower thinking I feared might be behind the decision (form over function, damn the users to hell, etc.) Really? I find that believing something should remain static at the expense of actual improvement to the language is far more 'ivory-tower thinking' than embracing change. First, to quote Tim Peters, practicality beats purity. Second, I might be biased here because I happen to know Warren, but, although he hails from the ivory tower, I imagine his concerns are purely practical. His contributions to software in structural biology are legendary. Am I the only one picking up on the irony here? as exists largely to provide a mechanism for working around namespace conflicts -- except, apparently, conflicts involving as. The fact that as itself creates an insurmountable namespace collision is just killing me! How absurd. Speaking of irony, you're complaining about namespace conflicts with a -two character identifier- you've chosen. Here's a hint: choose better names. The name fit his needs until changes in the language broke the name. If a name works and the code works, then the name is good enough. And speaking as a professional user of his software at the level of the application and at the level of the API, let me tell you his code works pretty damn good. But to be brutally honest...in this many-core world we must all accept and deal with today, it is hard to imagine how a non-multithreaded AND non-backwards compatible Python implementation can have much of a life ahead of it, with or without an as keyword. I do sincerely hope I am wrong about this, but it is seems quite possible that C/Python's glory days are now behind us. To match your honesty, I'm somewhat tired with the trend of some people to hit -one- issue with Python and suddenly lash out like children over all the same old tired crap. Have you even looked at multiprocessing? Have you contributed to any projects working on GIL- less implementations? Or are you just regurgitating the same bullet points we've heard time and time again? For chrissake, if you cannot do ANYTHING but BITCH about a change, then you've no damn right to consider yourself a programmer. Real programmers find solutions, not excuses. Correction: Real programmers write programs. And no, at this point he can't do anything but complain because, as others have noted, the change is not going away. And if so, then thank you all for so many wonderful years of effort and participation! You're welcome. Don't let the door hit you on the ass on your way out. You probably aren't a developer for the cPython implementation, but, if you were, I'd recommend taking rants like Warren's to heart because they are born of honest frustration and practical concern. Hopefully developers for python 2.7 are listening and won't break backward compatibility just because the Zen of Python suggests it might be a good idea. James -- James Stroud UCLA-DOE Institute for Genomics and Proteomics Box 951570 Los Angeles, CA 90095 http://www.jamesstroud.com -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On 2008-12-04 06:42, Warren DeLano wrote: Why can't the parser distinguish between a standalone as keyword and .as used as an object/attribute reference? Because that would require special-casing some names as being forbidden in syntax where other names are allowed. Special cases in language syntax are to be avoided where feasible. Am I the only one picking up on the irony here? as exists largely to provide a mechanism for working around namespace conflicts -- except, apparently, conflicts involving as. The fact that as itself creates an insurmountable namespace collision is just killing me! How absurd. Up until as has been special for many Python releases, ever since we introduced the from xyz import abc as def notation, so there's nothing new there. Now, instead of keeping that special status, it was decided to make it a reserved word since there's a new use case in Python 2.6 for it as well - catching exceptions: try: ... 1/0 ... except Exception as exc_object: ... print exc_object ... integer division or modulo by zero The Python developers always try very hard not to introduce new keywords to the language, but every now and then, it's better to go with the addition and cause some breakage. In this case, it's easy enough to find the files that break. Just run compileall.py on all your files and Python 2.6 will tell you which ones need fixing: python2.6 -c 'import compileall;compileall.compile_dir(.)' Anyway, it seems obvious that the right decision for our customers (or more importantly, for their countless lines of autogenerated-Python log, state, and code files from the past decade) is to stick with C/Python 2.5.x for the time being and plan to make the jump to a threads-capable and hopefully backwards-compatible Python implementation as soon as possible (IronPython perhaps?). That seems like a sensible path around the breakage and enduring limitations of C/Python 2.6 or 3. This idea of CPython not being threads-capable is FUD. CPython works perfectly well in multi-threaded environments. There are, of course, situations where using a multi-threaded approach is not necessarily the right way to approach a problem. For those you now have the multiprocessing module which allows creating and managing multiple processes to spread the load: http://docs.python.org/library/multiprocessing.html This also avoids many of the problems you face with multi-threading, e.g. managing low-level object access using thread locks, dealing with non-thread-aware code, finding all the instances of objects that would require thread-lock-managed access, etc. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-12-02: Released mxODBC.Connect 1.0.0 http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
One of the things I'd like to point out here is what we've been learning in new job during Induction Training... That is, it's part of the coding standard and design standards to name variables sensibly. For instance, naming a variable db when it's really a database object is a no no. Instead you should be naming it db. Another example, db_id vs. database_id. So my point here is that you should not really/ideally be naming variables with such short un-meaningful names such as as, if, id, xs or what not. Readability of your code becomes very important especially if you're working with many developers over time. 1. Use sensible meaningful names. 2. Don't use abbreviations. cheers James On Thu, Dec 4, 2008 at 8:43 PM, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 4 Dec 2008 01:28:56 -0800, Warren DeLano [EMAIL PROTECTED] declaimed the following in comp.lang.python: In addition, note that my choice of a concise method identifier affects only my users. Python's introduction of a new keyword affects the entire Python world code base, so perhaps you should be directing your choose better names criticism in another direction? Dropping in... If a chosen name mirrors a syntactic element -- whether reserved or not -- I'd consider that name potentially ambiguous or conflicted. While if has been long a reserved word, I can as easily see someone using if as a shorthand name for interface. And if if were not a reserved word, one might encounter code on the lines of if = if + 1 which is quite obnoxious to my eyes... or maybe if if.connected: if.close() Since import x as y has been a syntactic capability for some time, even if not reserved, I'd have avoided using as as anything other than that usage... -- WulfraedDennis 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 -- -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 4:43 am, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 4 Dec 2008 01:28:56 -0800, Warren DeLano [EMAIL PROTECTED] declaimed the following in comp.lang.python: In addition, note that my choice of a concise method identifier affects only my users. Python's introduction of a new keyword affects the entire Python world code base, so perhaps you should be directing your choose better names criticism in another direction? Dropping in... If a chosen name mirrors a syntactic element -- whether reserved or not -- I'd consider that name potentially ambiguous or conflicted. While if has been long a reserved word, I can as easily see someone using if as a shorthand name for interface. And if if were not a reserved word, one might encounter code on the lines of if = if + 1 which is quite obnoxious to my eyes... or maybe if if.connected: if.close() Does the OP hold the following should be legal? if if or or: and( for ) if not: while( def ) If not, it's an exception to Python's trend of not handcuffing programmers. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 3:28 am, Warren DeLano [EMAIL PROTECTED] wrote: Have you even looked at multiprocessing? Multiprocessing solves some problems, but it is unsuitable for high-frequency handoffs of large (in memory) objects between many independent threads/processes -- the HPC object/data flow parallelization model in a nutshell. I think 'mmap' combined with 'ctypes.Structure' is an underrated approach to such use cases. There is also POSH, Python Object Sharing. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Thu, Dec 4, 2008 at 9:04 PM, Aaron Brady [EMAIL PROTECTED] wrote: [... snip ...] Does the OP hold the following should be legal? if if or or: and( for ) if not: while( def ) I most certainly hope not! :) --JamesMills -- -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Thu, Dec 4, 2008 at 7:44 AM, James Stroud [EMAIL PROTECTED] wrote: alex23 wrote: On Dec 4, 3:42 pm, Warren DeLano [EMAIL PROTECTED] wrote: So you prefer broken code to broken rules, eh? Your customers must love that! This is exactly the kind of ivory-tower thinking I feared might be behind the decision (form over function, damn the users to hell, etc.) Really? I find that believing something should remain static at the expense of actual improvement to the language is far more 'ivory-tower thinking' than embracing change. First, to quote Tim Peters, practicality beats purity. Second, I might be biased here because I happen to know Warren, but, although he hails from the ivory tower, I imagine his concerns are purely practical. His contributions to software in structural biology are legendary. Am I the only one picking up on the irony here? as exists largely to provide a mechanism for working around namespace conflicts -- except, apparently, conflicts involving as. The fact that as itself creates an insurmountable namespace collision is just killing me! How absurd. Speaking of irony, you're complaining about namespace conflicts with a -two character identifier- you've chosen. Here's a hint: choose better names. The name fit his needs until changes in the language broke the name. If a name works and the code works, then the name is good enough. And speaking as a professional user of his software at the level of the application and at the level of the API, let me tell you his code works pretty damn good. But to be brutally honest...in this many-core world we must all accept and deal with today, it is hard to imagine how a non-multithreaded AND non-backwards compatible Python implementation can have much of a life ahead of it, with or without an as keyword. I do sincerely hope I am wrong about this, but it is seems quite possible that C/Python's glory days are now behind us. To match your honesty, I'm somewhat tired with the trend of some people to hit -one- issue with Python and suddenly lash out like children over all the same old tired crap. Have you even looked at multiprocessing? Have you contributed to any projects working on GIL- less implementations? Or are you just regurgitating the same bullet points we've heard time and time again? For chrissake, if you cannot do ANYTHING but BITCH about a change, then you've no damn right to consider yourself a programmer. Real programmers find solutions, not excuses. Correction: Real programmers write programs. And no, at this point he can't do anything but complain because, as others have noted, the change is not going away. And if so, then thank you all for so many wonderful years of effort and participation! You're welcome. Don't let the door hit you on the ass on your way out. You probably aren't a developer for the cPython implementation, but, if you were, I'd recommend taking rants like Warren's to heart because they are born of honest frustration and practical concern. Hopefully developers for python 2.7 are listening and won't break backward compatibility just because the Zen of Python suggests it might be a good idea. Even I, who am not, by really far, legendary on anything, could give my 2¢ one time or another on python-dev or python-ideas. If you really care and think you have a good argument, I'm sure you are welcome to post there! But they cant hold the release until everyone in the world have voiced his concerns, its just not pratical. -- Eduardo de Oliveira Padoan http://djangopeople.net/edcrypt/ Distrust those in whom the desire to punish is strong. -- Goethe, Nietzsche, Dostoevsky -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 7:28 pm, Warren DeLano [EMAIL PROTECTED] wrote: But who's leaving who exactly? Surely a language as beautiful as Python will easily transcend the limitations of its flagship implementation (if or to the extent that such an implementation cannot keep pace with the times). That's all well and good -- it may even end up being the next great leap forward for the language. I believe Guido has even said as much himself. Warren, thank you for a far more reasonable response than my post warranted. There seems a trend on this group for frustration to turn into ultimatums, which is what really triggered my outburst. Well, that and a crappy day at work. As for your above comment, I totally agree. It's probably the main outcome I'd like to see arise from the PyPy project: faster and easier experimentation with implementations. Nothing like some additional evolutionary pressure to make Python more fit. Good luck with resolving your current issue. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, 03 Dec 2008 17:15:21 -0800, Matimus wrote: Couldn't we have continued along just fine using a smarter parser without elevating as to reserved status (and thus potentially breaking a 10+ years of existing code)? Nothing broke your code. It works just fine under the version it was developed for. Who forced you to upgrade to python2.6? Be reasonable. Python 2.5 is not very far away from being put into security updates only mode, and in a year or so it won't even get security updates. I dare say there are already platforms that use Python 2.6 as standard. Tying your software to an obsolete version of a language is a good way to force your software into obsolescence. Not that 2.5 is obsolete *now*. But it will be soon (for some definition of soon): in no more than a year or three, software that only runs on Python 2.5 would be like software that only runs on 2.3 now. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Thu, 04 Dec 2008 20:53:38 +1000, James Mills wrote: Readability of your code becomes very important especially if you're working with many developers over time. 1. Use sensible meaningful names. 2. Don't use abbreviations. This is excellent advice, but remember, what is a sensible meaningful name is domain-specific. In a maths library, this would be sensible: def poly(x): return 4*x**3 -2*x**2 +3*x -7 and this ridiculous: def poly(real_number): return 4*real_number**3 -2*real_number**2 +3*real_number -7 Sometimes there are name clashes between keywords and sensible names in your problem space. I'm sure every regular Python developer has found themselves writing something like: prnt print_ print2 cls klass class_ or similar. In the standard library, the random module uses an argument lambd because lambda is a keyword. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, Dec 3, 2008 at 11:42 PM, Warren DeLano [EMAIL PROTECTED] wrote: Why was it necessary to make as a reserved keyword? I can't answer for the Python developers as to why they *did* make it a reserved word. But I can offer what I believe is a good reason why it *should* be a reserved word: Because simple is better than complex, and special cases aren't special enough to break the rules. So you prefer broken code to broken rules, eh? Your customers must love that! This is exactly the kind of ivory-tower thinking I feared might be behind the decision (form over function, damn the users to hell, etc.) remainder of creed skipped Honestly, based on the content and tenor of this post I think this is Yet Another Python Troll (the ivory tower reference, as well as the abrupt shift from complaining about keywords to multiprocessing), I have to point out that Python does add new keywords, it has done so in the past, and there was a considerable amount of warning, including an automated deprecation warning in the very version you are going to recommend to your customers' (I don't actually think you have any customers). If you suppressed or ignored the deprecation warning that all your code has been generating for at least 2 years it's pretty damn ballsy to come here and tell everyone how *Python* is doing something wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Thu, Dec 4, 2008 at 8:45 AM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Thu, 04 Dec 2008 20:53:38 +1000, James Mills wrote: Readability of your code becomes very important especially if you're working with many developers over time. 1. Use sensible meaningful names. 2. Don't use abbreviations. This is excellent advice, but remember, what is a sensible meaningful name is domain-specific. In a maths library, this would be sensible: def poly(x): return 4*x**3 -2*x**2 +3*x -7 and this ridiculous: def poly(real_number): return 4*real_number**3 -2*real_number**2 +3*real_number -7 I actually wonder. The former is sensible in a math context because there's a very long tradition in mathematics of using terse, inscrutable placeholders for terms. I'm not a mathematician and I don't know anything about the history of mathematical notation, but I'd guess this has something to do with the fact that maths has historically been done with a pencil and paper, and that terseness is an important quality when you have a limited canvas and lots of stuff to write. Aside from the cultural indoctrination, though (and that may be a real and strong force when dealing with math software, and I don't want to discount it in general, just for purposes of this discussion) why is it more sensible to use x here instead of number or real or real_number or something else? -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 6:08 am, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Wed, 03 Dec 2008 17:15:21 -0800, Matimus wrote: Couldn't we have continued along just fine using a smarter parser without elevating as to reserved status (and thus potentially breaking a 10+ years of existing code)? Nothing broke your code. It works just fine under the version it was developed for. Who forced you to upgrade to python2.6? Be reasonable. Python 2.5 is not very far away from being put into security updates only mode, and in a year or so it won't even get security updates. I dare say there are already platforms that use Python 2.6 as standard. Tying your software to an obsolete version of a language is a good way to force your software into obsolescence. Not that 2.5 is obsolete *now*. But it will be soon (for some definition of soon): in no more than a year or three, software that only runs on Python 2.5 would be like software that only runs on 2.3 now. -- Steven Here is the list of downloads from python.org: # Python 3.0 (December 3, 2008) # Python 2.6 (October 1, 2008) # Python 2.5.2 (February 22, 2008) # Python 2.4.5 (March 11, 2008) # Python 2.3.7 (March 11, 2008) Notice that Python 2.3 was given the update treatment in March of this year. I don't think I was being unreasonable. The point was that there is that new releases don't _break_ anything. You should always expect to have to test and update your code when going from Python2,x to Python2.(x+1). Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Warren DeLano wrote: Why was it necessary to make as a reserved keyword? Embrace the pain. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Thu, 4 Dec 2008 10:44:33 -0600 Chris Mellon [EMAIL PROTECTED] wrote: Aside from the cultural indoctrination, though (and that may be a real and strong force when dealing with math software, and I don't want to discount it in general, just for purposes of this discussion) why is it more sensible to use x here instead of number or real or real_number or something else? I think aside from doesn't really apply. It is habitual to write mathematics in shorthand. That is a, if not *the* factor to consider. Also: Variable names in programs tend to describe what those things *do* not what they are. If I call a variable number, the reader will usually none the wiser, because you deal with numbers a lot anyway. You'd call your numbers counter, height, pressure and the like. If however you do lots of numerical computations, your numbers tend to be just that, numbers. You'll gain nothing but confusion by calling them number1, number2, number3. They are then much easier to discern by calling them x, y and z. I think. /W -- My real email address is constructed by swapping the domain with the recipient (local part). -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Warren DeLano wrote: what I can't understand is the decision to break 2.6 instead of 3.0. 2.x was supposed to remain backwards compatible, with the thinking that 2.x would be maintained in parallel for quite some time. 3.x was supposed to be the compatibility break. I do not understand why anyone would object to this perfectly cogent complaint of Warren's. Even if the deprecation warnings had not been invisible, the complaint would be valid. Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 3, 11:42 pm, Warren DeLano [EMAIL PROTECTED] wrote: Except that Python syntax has proven itself to be a non-backwards compatible moving target. Eliminating cruft and adding new functionality is one thing, but introducing a whole new two-letter keyword so long after the game has begun? That seems well over the line of what can be considered reasonable. as has been in the language as a hybrid keyword/identifier since Python 2.0, released in 2000, and it was always the plan to eventually make it a full keyword. (I'm not sure when they decided to finish the job in 2.6.) They could have just made it a keyword right then and broke backwards compatibility instantly, instead they gave developers an eight year transition period. I think that is reasonable enough. You know, with Python being the kind of language that does have frequent releases which do carefully break backwards compatibility, if you are using it and expecting your code to work with future versions, it's your respsonsibility to keep up with planned language changes. You didn't. You were the one who dropped the ball here, not the Python developers. So stop complaining. If you don't want to take a few minutes a year to visit Python.org to see what changes are planned for upcoming releases, then feel free to use a language like Java that has the corporate backing to keep bad decisions around for decades. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 3:44 am, James Stroud [EMAIL PROTECTED] wrote: You probably aren't a developer for the cPython implementation, but, if you were, I'd recommend taking rants like Warren's to heart because they are born of honest frustration and practical concern. Hopefully developers for python 2.7 are listening and won't break backward compatibility just because the Zen of Python suggests it might be a good idea. I think they should. Python didn't get to where it is by being bogged down with obsolesence. It has grown and grown in popularity in spite of (and, I would say, in part because of) a history of backward- incompatible changes with every major release. It's not like Python has ignored the users; it's been very careful and considerate when making backwards-incompatible change. This change was planned for eight freaking years. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
It's been a while so I can't remember, but it seems like yield was dropped in to python relatively quickly in 2.2. Was there a similar outrage when yield became a keyword? -a -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 2:42 pm, Albert Hopkins [EMAIL PROTECTED] wrote: It's been a while so I can't remember, but it seems like yield was dropped in to python relatively quickly in 2.2. Was there a similar outrage when yield became a keyword? This is just one guy complaining. Yes, I'd imagine when yield and with were made into keywords there was probably someone, somewhere who complained about that, too. I doubt there will much outrage over as. It has been in the works for eight years and six releases, after all. Anyone who was paying attention wouldn't have been using as as an identifier. Among those who weren't paying attention, anyone smart wouldn't have been using as as an identifier because A) it is used as a syntactic element, and even if it's not a keyword it's poor style to use it also as an identifier, and B) you had to suspect sooner or later they would make it into a real keyword. Among those who were using as as an identifier, the vast majority will simply do an interactive search-and-replace to fix it. People like Warren here who have distributed codebases they can't easily fix up, and who were neither smart nor informed enough to avoid using as, are a pretty tiny minority, I would guess. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Thu, 04 Dec 2008 10:44:33 -0600, Chris Mellon wrote: On Thu, Dec 4, 2008 at 8:45 AM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Thu, 04 Dec 2008 20:53:38 +1000, James Mills wrote: Readability of your code becomes very important especially if you're working with many developers over time. 1. Use sensible meaningful names. 2. Don't use abbreviations. This is excellent advice, but remember, what is a sensible meaningful name is domain-specific. In a maths library, this would be sensible: def poly(x): return 4*x**3 -2*x**2 +3*x -7 and this ridiculous: def poly(real_number): return 4*real_number**3 -2*real_number**2 +3*real_number -7 I actually wonder. The former is sensible in a math context because there's a very long tradition in mathematics of using terse, inscrutable placeholders for terms. It's only inscrutable to those who don't speak the language, in the same way that those who don't read English would find The cat sat on the mat to be inscrutable, or those with no programming experience at all would find: if myList is not None: return [item.method() for item in myList.process()] fairly mystifying. It almost looks like English, but what's with the weird punctuation and non-standard use of capitals? I'm not a mathematician and I don't know anything about the history of mathematical notation, but I'd guess this has something to do with the fact that maths has historically been done with a pencil and paper, and that terseness is an important quality when you have a limited canvas and lots of stuff to write. I don't believe limited canvas is a major factor, because the availability of paper is only rarely a limiting factor. (However, there have been periods where paper or its equivalent was a rare and precious commodity.) Having lots of stuff to write by hand is a real factor though, especially since in a typical proof each line is very similar to the previous line. Aside from the cultural indoctrination, though (and that may be a real and strong force when dealing with math software, and I don't want to discount it in general, just for purposes of this discussion) why is it more sensible to use x here instead of number or real or real_number or something else? Because the long names actually distract from the essential semantics of the problem being worked on. Consider my example: return 4*x**3 -2*x**2 +3*x -7 Translated into English, this would mean: Think of a number and call it x, and by convention it is a real number; cube it and multiply by four; subtract two times the square of it; add three times it; subtract 7 Compare this: return 4*real_number**3 -2*real_number**2 +3*real_number -7 As a mathematician, I would read that as: Think of a number and call it real_number; cube it and multiply by four, and don't forget the number needs to be a real number; subtract two times the square of it, and remember the number is a real number; add three times it, and did I mention that it has to be a real number?; subtract 7 Explicit is not *always* better than implicit, and terseness *is* a virtue (up to a point!) which is why we don't do this: Define a function called myFunc which takes one argument called foo. The instructions to be executed when calling myFunc start here: if the value of the argument foo is identical to the value of the keyword None then: change the value of the argument foo to the result returned by the function calc_foo, passing no arguments to it otherwise do nothing ... but prefer the (slightly) terse and (moderately) implicit: def myFunc(foo, bar): if foo is None: foo = calc_foo() ... Thank goodness we don't have to program in verbose, explicit English! In general, most mathematical expressions will involve a small number of variables, and what they represent are obvious from context, at least for those familiar with the problem domain. Those who aren't familiar with the problem domain aren't expected to work on either developing the expression in the first place, or maintaining it, in whatever sense mathematics is expected to be maintained. Although the problem domain naively seems narrow (huh, who needs to understand complex numbers?) it is actually very abstract and hence can in principle be applied to many different problems. Contrast this with some arbitrary non-mathematical program. It might involve many variables rather than a few, and those variables might be rich objects with many attributes instead of simple numbers. The problem domain is often very concrete: *this* one specific business process, meaningful to only this department of that organisation, or at least to those just like them. Because concrete is more narrow than abstract, and because people who don't understand the problem domain are expected to maintain the software, you can't rely on implicit knowledge: you have to be explicit, and hence verbose, self-explanatory names
Re: as keyword woes
On Thu, 04 Dec 2008 08:44:19 -0800, Matimus wrote: The point was that there is that new releases don't _break_ anything. But that's clearly not true, because the OP is pointing out that the new release from 2.5 to 2.6 *does* break his code. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Warren DeLano wrote: A bottom line / pragmatic question... hopefully not a FAQ. Why was it necessary to make as a reserved keyword? cut Because it can be used at the import statement to let the imported thing be known under another name? Something like: import xml.etree.ElementTree as ET -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Martin P. Hellwig wrote: Warren DeLano wrote: A bottom line / pragmatic question... hopefully not a FAQ. Why was it necessary to make as a reserved keyword? cut Because it can be used at the import statement to let the imported thing be known under another name? Something like: import xml.etree.ElementTree as ET Sorry forget about the post, you know full well why not :-) -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, 2008-12-03 at 13:38 -0800, Warren DeLano wrote: A bottom line / pragmatic question... hopefully not a FAQ. Why was it necessary to make as a reserved keyword? And more to the point, why was it necessary to prevent developers from being able to refer to attributes named as? For example, this code breaks as of 2.6 / 3.0: Class C: Pass obj = C() obj.bs = 2 # valid obj.as = 1 # syntax error obj.cs = 3 # valid Just to be clear: I understand why it breaks, since as is now a keyword, I also know that one can use workarounds such as: obj.__dict__['as'] = 1 to maintain compatibility. What I want to understand is why this parser change was necessary in order to enable new 2.6/3.0 features. Was this change potentially avoidable? Why can't the parser distinguish between a standalone as keyword and .as used as an object/attribute reference? Couldn't we have continued along just fine using a smarter parser without elevating as to reserved status (and thus potentially breaking a 10+ years of existing code)? Thank you for enlighting me! (Unfortunately, our project may now have to maintain a branch at 2.5.x in order to preserve compatibility with existing third-party scripts infrastructure which routinely rely upon as as an object method. Sigh.) Cheers, Warren The short answer is that as is a keyword as of 2.6 (with the introduction of the with statement) and to be fair none of the other keywords can be identifiers. Also to be fair, there seems to be warning at least in my version of python 2.5: import sys sys.version_info (2, 5, 1, 'final', 0) class C: ... pass ... obj = C() obj.as = 3 stdin:1: Warning: 'as' will become a reserved keyword in Python 2.6 -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, 03 Dec 2008 22:02:24 +, Martin P. Hellwig wrote: Warren DeLano wrote: A bottom line / pragmatic question... hopefully not a FAQ. Why was it necessary to make as a reserved keyword? cut Because it can be used at the import statement to let the imported thing be known under another name? Something like: import xml.etree.ElementTree as ET Martin, that doesn't answer the OP's question *at all*. Python 2.5 uses as in that way, and it is not a keyword. import math as MATHS MATHS module 'math' from '/usr/lib/python2.5/lib-dynload/mathmodule.so' as = 45 stdin:1: Warning: 'as' will become a reserved keyword in Python 2.6 as stdin:1: Warning: 'as' will become a reserved keyword in Python 2.6 45 I'd guess that the change was to simplify the CPython parser. I have no idea if it was a tiny change or a significant change, if it made a huge difference to Python-dev or a little difference. Perhaps someone on the dev team could comment. While I feel sympathy for the OP, I do have to ask: he's been using Python 2.5 for, what, a couple of years now? How many times did he see the depreciation warning, and almost certainly the pending depreciation warning before that? Python-dev has been talking about making as a keyword since at least Python 2.3. Why wait until after version 2.6 is released before saying anything? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Because it can be used at the import statement to let the imported thing be known under another name? Something like: import xml.etree.ElementTree as ET Yes, but that syntax worked fine for years without as actually having to be a keyword. There must be something more going on here... I have to believe that was some reason or benefit gained from making it a keyword, and thus prohibiting its use anywhere else, as opposed to sticking with the status quo. Otherwise this would merely be a pointless change (perhaps even destructive!). -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Steven D'Aprano wrote: While I feel sympathy for the OP, I do have to ask: he's been using Python 2.5 for, what, a couple of years now? How many times did he see the depreciation warning, and almost certainly the pending depreciation warning before that? Python-dev has been talking about making as a keyword since at least Python 2.3. Why wait until after version 2.6 is released before saying anything? It's entirely possible that he did not see the warning. Python 2.5 has a bug where the warning gets silenced by an intervening import. http://bugs.python.org/issue3936 -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: [SPAM] Re: as keyword woes
Albert Hopkins wrote: On Wed, 2008-12-03 at 13:38 -0800, Warren DeLano wrote: A bottom line / pragmatic question... hopefully not a FAQ. Why was it necessary to make as a reserved keyword? And more to the point, why was it necessary to prevent developers from being able to refer to attributes named as? For example, this code breaks as of 2.6 / 3.0: Class C: Pass obj = C() obj.bs = 2 # valid obj.as = 1 # syntax error obj.cs = 3 # valid Just to be clear: I understand why it breaks, since as is now a keyword, I also know that one can use workarounds such as: obj.__dict__['as'] = 1 to maintain compatibility. What I want to understand is why this parser change was necessary in order to enable new 2.6/3.0 features. Was this change potentially avoidable? Why can't the parser distinguish between a standalone as keyword and .as used as an object/attribute reference? Couldn't we have continued along just fine using a smarter parser without elevating as to reserved status (and thus potentially breaking a 10+ years of existing code)? Thank you for enlighting me! (Unfortunately, our project may now have to maintain a branch at 2.5.x in order to preserve compatibility with existing third-party scripts infrastructure which routinely rely upon as as an object method. Sigh.) Cheers, Warren The short answer is that as is a keyword as of 2.6 (with the introduction of the with statement) and to be fair none of the other keywords can be identifiers. Also to be fair, there seems to be warning at least in my version of python 2.5: import sys sys.version_info (2, 5, 1, 'final', 0) class C: ... pass ... obj = C() obj.as = 3 stdin:1: Warning: 'as' will become a reserved keyword in Python 2.6 The parser in Python v2.5 can identify when as has its special meaning by context, but it's better to be consistent. Hopefully there won't be many reserved words (IIRC, COBOL has a _large_ number of them)! If you still want a name like that then the convention is to add a trailing underscore, eg the pass_ method of POP3 objects in poplib. That probably doesn't help you, though. :-( -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 3, 4:38 pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Wed, 03 Dec 2008 22:02:24 +, Martin P. Hellwig wrote: Warren DeLano wrote: A bottom line / pragmatic question... hopefully not a FAQ. Why was it necessary to make as a reserved keyword? cut Because it can be used at the import statement to let the imported thing be known under another name? Something like: import xml.etree.ElementTree as ET Martin, that doesn't answer the OP's question *at all*. Python 2.5 uses as in that way, and it is not a keyword. import math as MATHS MATHS module 'math' from '/usr/lib/python2.5/lib-dynload/mathmodule.so' as = 45 stdin:1: Warning: 'as' will become a reserved keyword in Python 2.6 as stdin:1: Warning: 'as' will become a reserved keyword in Python 2.6 45 I'd guess that the change was to simplify the CPython parser. I have no idea if it was a tiny change or a significant change, if it made a huge difference to Python-dev or a little difference. Perhaps someone on the dev team could comment. While I feel sympathy for the OP, I do have to ask: he's been using Python 2.5 for, what, a couple of years now? How many times did he see the depreciation warning, and almost certainly the pending depreciation warning before that? Python-dev has been talking about making as a keyword since at least Python 2.3. Why wait until after version 2.6 is released before saying anything? When I brought this up a short while ago (because sympy crashed in Python 2.6) someone said that there was a bug in Python 2.5 that prevented the display of the deprecation message (when as appeared inside imported modules). So apparently, the sympy developers never saw a deprecation warning in all the years they were using 2.5. There was, however, no excuse for not testing it in 2.6. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Warren DeLano [EMAIL PROTECTED] writes: Why was it necessary to make as a reserved keyword? I can't answer for the Python developers as to why they *did* make it a reserved word. But I can offer what I believe is a good reason why it *should* be a reserved word: Because simple is better than complex, and special cases aren't special enough to break the rules. And more to the point, why was it necessary to prevent developers from being able to refer to attributes named as? There aren't special rules for which names can be use in which way, and that's a *good* thing. Any name that is valid in one area of Python syntax is valid in all Python syntax. Why can't the parser distinguish between a standalone as keyword and .as used as an object/attribute reference? Because that would require special-casing some names as being forbidden in syntax where other names are allowed. Special cases in language syntax are to be avoided where feasible. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but this time *you* put the trousers on the chimp.” | _o__) —_Pinky and The Brain_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Steven D'Aprano wrote: On Wed, 03 Dec 2008 22:02:24 +, Martin P. Hellwig wrote: Warren DeLano wrote: A bottom line / pragmatic question... hopefully not a FAQ. Why was it necessary to make as a reserved keyword? cut Because it can be used at the import statement to let the imported thing be known under another name? Something like: import xml.etree.ElementTree as ET Martin, that doesn't answer the OP's question *at all*. Python 2.5 uses as in that way, and it is not a keyword. Yes Steven, I realized after the apple fell on my head that I was barking at the wrong tree, in a totally different forest, sorry for the noise. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
What I want to understand is why this parser change was necessary in order to enable new 2.6/3.0 features. Was this change potentially avoidable? Does it really matter? The change occurred and it isn't going to go back. What you should be asking yourself is whether the affect it had on your code could have been avoided. What could you have done to prevent your current situation? Couldn't we have continued along just fine using a smarter parser without elevating as to reserved status (and thus potentially breaking a 10+ years of existing code)? Nothing broke your code. It works just fine under the version it was developed for. Who forced you to upgrade to python2.6? 'as' was already coming close to being a keyword with its use in import statements. It be came a full fledged keyword to support context managers: with open('filename.x', 'w') as fout: # do stuff (Unfortunately, our project may now have to maintain a branch at 2.5.x in order to preserve compatibility with existing third-party scripts infrastructure which routinely rely upon as as an object method. Sigh.) Not necessarily. You can do something like this: import sys import warnings class MyClass(object): def new_as(self): # call this something appropriate, it is your new 'as' method pass # do what 'as' does if sys.version[:3] = '2.5': def _old_as(self): warnings.warn( DeprecationWarning( 'This method is deprecated, use `new_as` instead')) return self.new_as() exec 'as = _old_as' You could even write a metaclass that does this (a little more elegantly). Your users will get a nice warning telling them not to use the 'as' method anymore. It will work in both code bases, and you can schedule to remove it at some later version after customers have had the opportunity to remove 'as' from their code. Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
Warren DeLano [EMAIL PROTECTED] writes: But I can offer what I believe is a good reason why it *should* be a reserved word: Because simple is better than complex, and special cases aren't special enough to break the rules. So you prefer broken code to broken rules, eh? Your customers must love that! This is exactly the kind of ivory-tower thinking I feared might be behind the decision (form over function, damn the users to hell, etc.) I don't know how you infer any of those from what I said, nor from the process of introducing features in Python. None of what you say there rings at all true with anything I've experienced in Python's core or the attitudes surrounding development if the language; indeed, quite the opposite. Anyway, it seems obvious that the right decision for our customers (or more importantly, for their countless lines of autogenerated-Python log, state, and code files from the past decade) is to stick with C/Python 2.5.x for the time being […] This is an entirely reasonable and viable option, all the more so because of the comprehensive work done by the Python developers to continue the viability of the Python 2.x line and ease introduction of new features. Best of luck pursuing your goals. -- \ “I'd like to see a nude opera, because when they hit those high | `\ notes, I bet you can really see it in those genitals.” —Jack | _o__) Handey | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Dec 4, 3:42 pm, Warren DeLano [EMAIL PROTECTED] wrote: So you prefer broken code to broken rules, eh? Your customers must love that! This is exactly the kind of ivory-tower thinking I feared might be behind the decision (form over function, damn the users to hell, etc.) Really? I find that believing something should remain static at the expense of actual improvement to the language is far more 'ivory-tower thinking' than embracing change. Am I the only one picking up on the irony here? as exists largely to provide a mechanism for working around namespace conflicts -- except, apparently, conflicts involving as. The fact that as itself creates an insurmountable namespace collision is just killing me! How absurd. Speaking of irony, you're complaining about namespace conflicts with a -two character identifier- you've chosen. Here's a hint: choose better names. But to be brutally honest...in this many-core world we must all accept and deal with today, it is hard to imagine how a non-multithreaded AND non-backwards compatible Python implementation can have much of a life ahead of it, with or without an as keyword. I do sincerely hope I am wrong about this, but it is seems quite possible that C/Python's glory days are now behind us. To match your honesty, I'm somewhat tired with the trend of some people to hit -one- issue with Python and suddenly lash out like children over all the same old tired crap. Have you even looked at multiprocessing? Have you contributed to any projects working on GIL- less implementations? Or are you just regurgitating the same bullet points we've heard time and time again? For chrissake, if you cannot do ANYTHING but BITCH about a change, then you've no damn right to consider yourself a programmer. Real programmers find solutions, not excuses. And if so, then thank you all for so many wonderful years of effort and participation! You're welcome. Don't let the door hit you on the ass on your way out. -- http://mail.python.org/mailman/listinfo/python-list