Re: [Python-Dev] "as" keyword woes
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "as" keyword woes
On Sun, Dec 7, 2008 at 1:06 PM, Paul Boddie <[EMAIL PROTECTED]> 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
>> 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/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 > 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "as" keyword woes
> Date: Sat, 6 Dec 2008 12:13:16 -0800 (PST) > From: Carl Banks <[EMAIL PROTECTED]> > Subject: Re: "as" keyword woes > To: [EMAIL PROTECTED] > 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "as" keyword woes
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)
You could make a PEP if you really wanted to, but it's going to be rejected.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "as" keyword woes
On 06 Dec 2008, at 20:38, Warren DeLano 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 "a"s?
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
As long as "as" is widely known as a keyword, I don't see the problem.
Every python developer knows that the convention is to add a trailing
underscore when you want to use a reserved word in your code. Besides,
your examples are quite abstract. I'm sure it's possible to find good
examples for "while", "with", "import", "from" (I often use "from_")
or "try" as well. Or perhaps that the python keywords should be "as_"
so we leave "as" free for eventual methods?
As for the implicit proposition of allowing keywords only for methods,
I agree with Guido about it being a slippery slope. So we would end up
with a language where it is allowed to name methods after keywords,
but not functions (they can be declared in the local scope)? Yikes! Oh
well, maybe it's possible for an intelligent parser to distinguish
between keywords and function references, but think of the poor
grammar highlighters in all source editors! What a nightmare it will
be for them. Anyway, is there any language that does this, allowing
keywords as method names? I don't know, but if not, there's probably a
reason for it.
Your views on code elegance are also rather Javaish. I'd go for
"class_reference(object)" (and why the heck would you "be limited to
using method for casting"?).
Ciao,
Virgil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "as" keyword woes
On Sat, Dec 6, 2008 at 11:38 AM, 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. Well, that's too bad, as 'as' is now a reserved word. > 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. If you had brought this up 5-10 years ago when we first introduced 'as' as a semi-keyword (in the import statement) we might have been able to avert this disaster. As it was, nobody ever brought this up AFICR, so I don't think it's *that* 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. 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. Otherwise *every* reserved word would have to be allowed right after a '.', and many keywords would have to be allowed as identifiers in other contexts. That way lies PL/1... Furthermore, how would you define the 'as' method? Would you also want to be allowed to write def as(self, target): ... ??? Trust me, it's a slippery slope, and you don't want to start going down there. > 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "as" keyword woes
Warren DeLano 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. How about "to"? Almost every language I have ever used uses "to" and not "as". Python predominately uses "to" already, so why would you fight that? And moreover, I have never seen a language or library that preferred "as", so I remain to be convinced that "as" is a good choice. > 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 not a matter of whether it is possible. It's a matter of simplicity and a lack of a worthy use-case for allowing it. In general, the trend has been to not allow any keywords as identifiers in the Python language. If there were such a worthy use-case, then what is really import is that it increases the complexity of /the language/ a human programmer needs to parse. > 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 will need to work on making a convincing argument as to why the keyword "as" is anymore special than say "for", or any other keywords for that matter. Unless you plan on proposing a reversal of the current keyword/identifier ideology, which is likely to be reject outright. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "as" keyword woes
> 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 "a"s?
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
