Re: [Python-Dev] "as" keyword woes
On Sat Dec 6 21:29:09 CET 2008, Guido van Rossum wrote:
On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano <warren at delsci.com> 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.
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. Reserved words are reserved in all contexts, regardless of whether ambiguity could arise.
Just a quick aside from someone who merely lurks on this list: in SQL, it's quite possible to use keywords in a fashion similar to that desired by the inquirer, and it's actually possible to double-quote keywords and use them as names for things. I'm not advocating more complicated parsing technology for any Python implementation, but I think it's pertinent to point out that the technology isn't particularly obscure. Apologies for the interruption, Paul
On Sun, Dec 7, 2008 at 1:06 PM, Paul Boddie <paul@boddie.org.uk> wrote:
On Sat Dec 6 21:29:09 CET 2008, Guido van Rossum wrote:
On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano <warren at delsci.com> 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.
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. Reserved words are reserved in all contexts, regardless of whether ambiguity could arise.
Just a quick aside from someone who merely lurks on this list: in SQL, it's quite possible to use keywords in a fashion similar to that desired by the inquirer, and it's actually possible to double-quote keywords and use them as names for things. I'm not advocating more complicated parsing technology for any Python implementation, but I think it's pertinent to point out that the technology isn't particularly obscure.
From my experience with SQL, it's nearly as bad as Python in that every single one of the 200+ reserved words in a typical implementation cannot be used as a name in any context without using double quotes. While the double-quote escape is handy (especially given there are so many obscure reserved words) this is not exactly what the OP wanted -- they would have to say x."as"('float'), except using some other notation instead of double quotes. Having to escape it completely kills the OP's claim that 'as' is "simplest and most elegant".
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Monday 08 December 2008 22:54:41 Guido van Rossum wrote:
From my experience with SQL, it's nearly as bad as Python in that every single one of the 200+ reserved words in a typical implementation cannot be used as a name in any context without using double quotes.
SQL is a big language; I won't disagree with that! That said, you don't always have to quote names like "end" as I mention below.
While the double-quote escape is handy (especially given there are so many obscure reserved words) this is not exactly what the OP wanted -- they would have to say x."as"('float'), except using some other notation instead of double quotes. Having to escape it completely kills the OP's claim that 'as' is "simplest and most elegant".
You can do what the OP wants, at least in PostgreSQL, which is fairly conformant. As I wrote on comp.lang.python... create table "create" ( "select" varchar ); select "select" from "create"; select "create".select from "create"; (This from a PostgreSQL 8.2 session.) I don't know whether SQL 1992 actually allows dropping the double-quotes for column names, but this is the kind of thing he has in mind. Paul
participants (2)
-
Guido van Rossum -
Paul Boddie