Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"as" keyword woes

3 views
Skip to first unread message

Warren DeLano

unread,
Dec 3, 2008, 4:38:23 PM12/3/08
to pytho...@python.org

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


Martin P. Hellwig

unread,
Dec 3, 2008, 5:02:24 PM12/3/08
to
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

Martin P. Hellwig

unread,
Dec 3, 2008, 5:04:58 PM12/3/08
to
Sorry forget about the post, you know full well why not :-)

--
mph

Albert Hopkins

unread,
Dec 3, 2008, 5:12:27 PM12/3/08
to pytho...@python.org
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?
>

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

Steven D'Aprano

unread,
Dec 3, 2008, 5:38:22 PM12/3/08
to

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

Warren DeLano

unread,
Dec 3, 2008, 5:49:19 PM12/3/08
to pytho...@python.org
> 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!).


Robert Kern

unread,
Dec 3, 2008, 6:15:48 PM12/3/08
to pytho...@python.org
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

MRAB

unread,
Dec 3, 2008, 6:17:46 PM12/3/08
to pytho...@python.org
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?
>>
> <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. :-(

Mensanator

unread,
Dec 3, 2008, 7:08:23 PM12/3/08
to
On Dec 3, 4:38 pm, Steven D'Aprano <st...@REMOVE-THIS-

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

Ben Finney

unread,
Dec 3, 2008, 7:16:49 PM12/3/08
to
"Warren DeLano" <war...@delsci.com> 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

Martin P. Hellwig

unread,
Dec 3, 2008, 7:55:59 PM12/3/08
to
Steven D'Aprano wrote:
> On Wed, 03 Dec 2008 22:02:24 +0000, 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

Matimus

unread,
Dec 3, 2008, 8:15:21 PM12/3/08
to
> 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

Warren DeLano

unread,
Dec 4, 2008, 12:42:37 AM12/4/08
to pytho...@python.org
> > 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.)

> > 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.

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.

> > 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.

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.

Or in other words, if we're all going to go through a Python
compatibility-disconnect, then we might as well kill as many birds as
possible in a single pass -- and that single-threaded interpreter bird
is definitely a "dodo" in danger of extinction.

By the way, congratulations on 3.0 final!

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.

And if so, then thank you all for so many wonderful years of effort and
participation! C/Python has had a great run, and Python syntax, in a
multiplicity of forms, will surely live on for many decades to come.
Python has changed the world, and very much so for the better.

Well done!

Cheers,
Warren

Ben Finney

unread,
Dec 4, 2008, 1:36:44 AM12/4/08
to
"Warren DeLano" <war...@delsci.com> 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

alex23

unread,
Dec 4, 2008, 2:13:18 AM12/4/08
to
On Dec 4, 3:42 pm, "Warren DeLano" <war...@delsci.com> 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.

Warren DeLano

unread,
Dec 4, 2008, 4:28:56 AM12/4/08
to pytho...@python.org

> 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



James Stroud

unread,
Dec 4, 2008, 4:44:50 AM12/4/08
to
alex23 wrote:
> On Dec 4, 3:42 pm, "Warren DeLano" <war...@delsci.com> 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

M.-A. Lemburg

unread,
Dec 4, 2008, 5:22:34 AM12/4/08
to Warren DeLano, pytho...@python.org
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

Message has been deleted

James Mills

unread,
Dec 4, 2008, 5:53:38 AM12/4/08
to Dennis Lee Bieber, pytho...@python.org
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 <wlf...@ix.netcom.com> wrote:
> On Thu, 4 Dec 2008 01:28:56 -0800, "Warren DeLano" <war...@delsci.com>
> 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...
> --
> Wulfraed Dennis Lee Bieber KD6MOG
> wlf...@ix.netcom.com wulf...@bestiaria.com
> HTTP://wlfraed.home.netcom.com/
> (Bestiaria Support Staff: web-...@bestiaria.com)
> HTTP://www.bestiaria.com/
> --
> http://mail.python.org/mailman/listinfo/python-list
>

--
--
-- "Problems are solved by method"

Aaron Brady

unread,
Dec 4, 2008, 6:04:54 AM12/4/08
to
On Dec 4, 4:43 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> On Thu, 4 Dec 2008 01:28:56 -0800, "Warren DeLano" <war...@delsci.com>
> 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.

Aaron Brady

unread,
Dec 4, 2008, 6:10:16 AM12/4/08
to
On Dec 4, 3:28 am, "Warren DeLano" <war...@delsci.com> 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.

James Mills

unread,
Dec 4, 2008, 6:17:34 AM12/4/08
to Aaron Brady, pytho...@python.org
On Thu, Dec 4, 2008 at 9:04 PM, Aaron Brady <casti...@gmail.com> 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

Eduardo O. Padoan

unread,
Dec 4, 2008, 6:25:50 AM12/4/08
to James Stroud, pytho...@python.org


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

alex23

unread,
Dec 4, 2008, 7:22:32 AM12/4/08
to
On Dec 4, 7:28 pm, "Warren DeLano" <war...@delsci.com> 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.

Steven D'Aprano

unread,
Dec 4, 2008, 9:08:30 AM12/4/08
to
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

Steven D'Aprano

unread,
Dec 4, 2008, 9:45:46 AM12/4/08
to
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

Chris Mellon

unread,
Dec 4, 2008, 11:39:26 AM12/4/08
to pytho...@python.org
On Wed, Dec 3, 2008 at 11:42 PM, Warren DeLano <war...@delsci.com> 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.

Matimus

unread,
Dec 4, 2008, 11:44:19 AM12/4/08
to
On Dec 4, 6:08 am, Steven D'Aprano <st...@REMOVE-THIS-

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

Chris Mellon

unread,
Dec 4, 2008, 11:44:33 AM12/4/08
to pytho...@python.org
On Thu, Dec 4, 2008 at 8:45 AM, Steven D'Aprano
<st...@remove-this-cybersource.com.au> 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?

John Nagle

unread,
Dec 4, 2008, 12:24:54 PM12/4/08
to
> Warren DeLano wrote:
>> Why was it necessary to make "as" a reserved keyword?

Embrace the pain.

John Nagle

Warren DeLano

unread,
Dec 4, 2008, 12:32:00 PM12/4/08
to pytho...@python.org
> 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.

Thank you for finally answering my original question. If the above use
(or that of with), for implementation reasons, *requires* "as" to be a
keyword, then I can understand their decision to break Python. But 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. Not so, apparently.

> 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(".")'

But that assumes source code is a closed set. Unfortunately, in our
case, our code actually writes new Python code itself in the form of
document-like-objects intended for future re-execution. In that sense,
our code base is an open set relying upon Python's backward
compatibility (albeit in a very limited ways, but no source code can be
immune to introduction of new language keywords).



> This idea of CPython not being threads-capable is FUD. CPython
> works perfectly well in multi-threaded environments.

With all due respect, calling CPython out on the fact that it delivers
the efficiency of only one single CPU core even when there are N Python
threads running with N-1 idle cores available on a system is not
misleading FUD. It is the truth.

With all due respect, calling CPython out on the fact that its
developer-users cannot even work around this problem elegantly by
instantiating multiple independent Python interpreters running
concurrently within a single process (with limited but well defined
channels of communication between them) is not misleading FUD. It is
also the truth.

Given that the next round of high-end workstations will likely have
12-16 cores, N CPython native threads will be more than an order of
magnitude (>10 fold) less efficient than N Python-like threads on a true
threads-capable VM like the CLR. 3-4 years later, it will be 100-fold
less efficient, and on and on, in a 1/(2^T) geometric rate of declining
performance. That is near-term reality, not misleading FUD.

That the powers-that-be consider the above situation working "perfectly
well in multi-threaded environments" is rather telling. That the
CPython 3.0 compatibility-break was finalized without resolution of
CPython's thread performance issues should absolutely give rise to
well-founded Fear, Uncertainty, and Doubt about the utility of the
CPython 3.0 VM implementation in the minds of current users who must
deliver performant software for a living.

> There are, of course, situations where using a multi-threaded approach
> is not necessarily the right way to approach a problem.

Yes, we have been lectured about this endlessly. We are told that
threads are bad for various reasons, that they aren't ever the right
solution, that we should be using shared memory, separate processes, or
native code, or that real multithreading would break CPython library
compatibility (!) and so on, all despite the fact that threads work
perfectly fine in other VMs, including some VMs which run Python
dialects. Threads are indeed the optimal solution to certain problems,
and those problems are still not solvable with CPython 3.0.

Is it too much to hold out hope for a native Pythonic solution to the
multithreading performance issues inside of the CPython VM itself? Only
time will tell... but time is rapidly running out.

Warren

Andreas Waldenburger

unread,
Dec 4, 2008, 2:41:21 PM12/4/08
to
On Thu, 4 Dec 2008 10:44:33 -0600 "Chris Mellon" <ark...@gmail.com>
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).

Alan G Isaac

unread,
Dec 4, 2008, 3:15:22 PM12/4/08
to
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

Carl Banks

unread,
Dec 4, 2008, 3:19:44 PM12/4/08
to
On Dec 3, 11:42 pm, "Warren DeLano" <war...@delsci.com> 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

Carl Banks

unread,
Dec 4, 2008, 3:32:08 PM12/4/08
to
On Dec 4, 3:44 am, James Stroud <jstr...@mbi.ucla.edu> 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

Albert Hopkins

unread,
Dec 4, 2008, 3:42:31 PM12/4/08
to pytho...@python.org
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

Warren DeLano

unread,
Dec 4, 2008, 3:53:53 PM12/4/08
to pytho...@python.org
> I still have not
> >> seen a single post from you even hinting that you might have any
> >> responsibility in the matter.
> >
> > Well then, let me set the record straight on that one point:
> >
> > I admit that it was entirely my mistake (and mine alone) to
implicitly
> > assume, by adopting such a logging & persistence architecture
(dating
> > back to 1.5.2, mind you!), that new keywords would not be introduced
> > into the Python language so as to potentially break all existing
Python
> > code.
> >
> > Silly me! How unreasonable.
> >
>
> Pythons backwards compatibility policy is available here:
> http://www.python.org/dev/peps/pep-0005/

Thank you! Just to end on a more positive note:

As someone who makes a living from Python rather than someone who lives
to make Python, I recognize that there will be ancillary casualties in
every major battle.

Though I may whine incessantly about all of our pre-2.5
log-file/documents being one such casualty (your various accusations
notwithstanding, we did indeed patch our own code as soon as the
deprecation warnings appeared in 2.5!), if the Python 2.6 "as" keyword
break is truly for the greater good, then so be it.

Warren


Carl Banks

unread,
Dec 4, 2008, 4:08:46 PM12/4/08
to

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

Steven D'Aprano

unread,
Dec 4, 2008, 5:29:41 PM12/4/08
to
On Thu, 04 Dec 2008 10:44:33 -0600, Chris Mellon wrote:

> On Thu, Dec 4, 2008 at 8:45 AM, Steven D'Aprano
> <st...@remove-this-cybersource.com.au> 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 are a virtue.


--
Steven

Steven D'Aprano

unread,
Dec 5, 2008, 12:21:25 AM12/5/08
to
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

Andreas Waldenburger

unread,
Dec 5, 2008, 10:09:30 AM12/5/08
to
On 04 Dec 2008 22:29:41 GMT Steven D'Aprano
<st...@REMOVE-THIS-cybersource.com.au> 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

:)

Message has been deleted
Message has been deleted

Mensanator

unread,
Dec 6, 2008, 12:02:34 PM12/6/08
to
On Dec 6, 8:16�am, Wolfgang Strobl <ne...@mystrobl.de> wrote:
> Dennis Lee Bieber <wlfr...@ix.netcom.com>:
>
> >On 05 Dec 2008 05:21:25 GMT, Steven D'Aprano
> ><st...@REMOVE-THIS-cybersource.com.au> declaimed the following in
> >comp.lang.python:
>
> > � �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:\Python26>python
> 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

MRAB

unread,
Dec 6, 2008, 12:54:55 PM12/6/08
to pytho...@python.org
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.

Warren DeLano

unread,
Dec 6, 2008, 2:38:51 PM12/6/08
to pytho...@python.org, pytho...@python.org

> Date: Fri, 05 Dec 2008 22:22:38 -0800
> From: Dennis Lee Bieber <wlf...@ix.netcom.com>
> Subject: Re: "as" keyword woes
> To: pytho...@python.org
> Message-ID: <bqadnTS6jM21h6fU...@earthlink.com>
>
> 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? <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

Message has been deleted

Terry Reedy

unread,
Dec 6, 2008, 3:12:02 PM12/6/08
to pytho...@python.org
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

Carl Banks

unread,
Dec 6, 2008, 3:13:16 PM12/6/08
to
On Dec 6, 1:38 pm, "Warren DeLano" <war...@delsci.com> 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

Lie

unread,
Dec 6, 2008, 3:18:14 PM12/6/08
to
On Dec 7, 2:38 am, "Warren DeLano" <war...@delsci.com> wrote:
> > Date: Fri, 05 Dec 2008 22:22:38 -0800
> > From: Dennis Lee Bieber <wlfr...@ix.netcom.com>

> > Subject: Re: "as" keyword woes
> > To: python-l...@python.org
> > Message-ID: <bqadnTS6jM21h6fUnZ2dnUVZ_uydn...@earthlink.com>

And let things like:

filelike.print('lpt') # python 2.6
zipper.with('7z')
failure.try(alternative)
executecodeobject.if(True)
onfailure.break()

?

Guido van Rossum

unread,
Dec 6, 2008, 3:29:09 PM12/6/08
to Warren DeLano, pytho...@python.org, pytho...@python.org
On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano <war...@delsci.com> 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/)

Terry Reedy

unread,
Dec 6, 2008, 4:47:15 PM12/6/08
to pytho...@python.org, pytho...@python.org
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

Mensanator

unread,
Dec 6, 2008, 5:36:07 PM12/6/08
to
On Dec 6, 2:09�pm, Wolfgang Strobl <ne...@mystrobl.de> wrote:
> Mensanator <mensana...@aol.com>:

>
>
>
>
>
> >On Dec 6, 8:16?am, Wolfgang Strobl <ne...@mystrobl.de> wrote:
> >> Dennis Lee Bieber <wlfr...@ix.netcom.com>:
>
> >> >On 05 Dec 2008 05:21:25 GMT, Steven D'Aprano
> >> ><st...@REMOVE-THIS-cybersource.com.au> 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:\Python26>python
> >> 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.

Virgil Dupras

unread,
Dec 6, 2008, 6:01:39 PM12/6/08
to Warren DeLano, pytho...@python.org, pytho...@python.org
On 06 Dec 2008, at 20:38, Warren DeLano wrote:

>
>> Date: Fri, 05 Dec 2008 22:22:38 -0800

>> From: Dennis Lee Bieber <wlf...@ix.netcom.com>


>> Subject: Re: "as" keyword woes

>> To: pytho...@python.org
>> Message-ID: <bqadnTS6jM21h6fU...@earthlink.com>

> 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

Steven D'Aprano

unread,
Dec 6, 2008, 7:25:04 PM12/6/08
to
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

Nick Coghlan

unread,
Dec 6, 2008, 8:27:56 PM12/6/08
to Warren DeLano, pytho...@python.org, pytho...@python.org
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 | ncog...@gmail.com | Brisbane, Australia
---------------------------------------------------------------

Mensanator

unread,
Dec 6, 2008, 9:09:07 PM12/6/08
to
On Dec 6, 6:25�pm, Steven D'Aprano <st...@REMOVE-THIS-

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

Steven D'Aprano

unread,
Dec 6, 2008, 9:17:58 PM12/6/08
to
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.)

I'd prefer a method like obj.make_from(type) or obj.export_as(type) or
similar. It's more verbose than "as" but its more explicit about what it
does. obj.as(type) is ambiguous, because it could mean any "return a new
object of type made from obj", "return obj inside a wrapper that makes it
behave as if it were type", "convert obj to type in place".


--
Steven

Steven D'Aprano

unread,
Dec 6, 2008, 10:09:23 PM12/6/08
to
On Sat, 06 Dec 2008 18:09:07 -0800, Mensanator wrote:

> On Dec 6, 6:25�pm, Steven D'Aprano <st...@REMOVE-THIS-
> 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

Carl Banks

unread,
Dec 6, 2008, 10:35:42 PM12/6/08
to
On Dec 6, 8:17 pm, Steven D'Aprano <st...@REMOVE-THIS-

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

Mensanator

unread,
Dec 6, 2008, 11:16:56 PM12/6/08
to
On Dec 6, 9:09�pm, Steven D'Aprano <st...@REMOVE-THIS-

cybersource.com.au> wrote:
> On Sat, 06 Dec 2008 18:09:07 -0800, Mensanator wrote:
> > On Dec 6, 6:25 pm, Steven D'Aprano <st...@REMOVE-THIS-
> > 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

Warren DeLano

unread,
Dec 6, 2008, 11:19:08 PM12/6/08
to pytho...@python.org, pytho...@python.org
> Date: Sat, 6 Dec 2008 12:13:16 -0800 (PST)
> From: Carl Banks <pavlove...@gmail.com>

> Subject: Re: "as" keyword woes
> To: pytho...@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

Aaron Brady

unread,
Dec 7, 2008, 6:16:56 AM12/7/08
to
On Dec 6, 2:29 pm, "Guido van Rossum" <gu...@python.org> 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.

Aaron Brady

unread,
Dec 7, 2008, 6:26:08 AM12/7/08
to
On Dec 6, 9:35 pm, Carl Banks <pavlovevide...@gmail.com> wrote:
> On Dec 6, 8:17 pm, Steven D'Aprano <st...@REMOVE-THIS-
> > 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:

3f800000 1.000000

Sorry for the tangent.

r0g

unread,
Dec 8, 2008, 1:14:44 PM12/8/08
to
Virgil Dupras wrote:
> On 06 Dec 2008, at 20:38, Warren DeLano wrote:
<snip>

> 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.

Ooo, actually I didn't know that (see my last post!), thanks :-)


Roger.

Paul Boddie

unread,
Dec 8, 2008, 2:21:55 PM12/8/08
to
On Dec 4, 5:39 pm, "Chris Mellon" <arka...@gmail.com> 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

J. Cliff Dyer

unread,
Dec 8, 2008, 3:07:22 PM12/8/08
to Warren DeLano, pytho...@python.org

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


alex23

unread,
Dec 8, 2008, 11:52:32 PM12/8/08
to
On Dec 9, 5:21 am, Paul Boddie <p...@boddie.org.uk> 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 :)

Gabriel Genellina

unread,
Dec 9, 2008, 1:59:10 AM12/9/08
to pytho...@python.org
En Mon, 08 Dec 2008 18:07:22 -0200, J. Cliff Dyer <j...@sdf.lonestar.org>
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

Paul Boddie

unread,
Dec 9, 2008, 7:39:55 AM12/9/08
to
On 9 Des, 05:52, alex23 <wuwe...@gmail.com> 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

BJörn Lindqvist

unread,
Dec 9, 2008, 7:54:15 AM12/9/08
to Chris Mellon, pytho...@python.org
2008/12/4 Chris Mellon <ark...@gmail.com>:
> 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

Steven D'Aprano

unread,
Dec 9, 2008, 8:24:32 AM12/9/08
to
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

Paul Boddie

unread,
Dec 9, 2008, 8:48:29 AM12/9/08
to
On 9 Des, 14:24, Steven D'Aprano <st...@REMOVE-THIS-

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

MRAB

unread,
Dec 9, 2008, 9:28:51 AM12/9/08
to pytho...@python.org
Paul Boddie wrote:
> On 9 Des, 14:24, Steven D'Aprano <st...@REMOVE-THIS-
> 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
>

Aaron Brady

unread,
Dec 9, 2008, 11:30:26 AM12/9/08
to
On Dec 9, 8:28 am, MRAB <goo...@mrabarnett.plus.com> 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?

George Sakkis

unread,
Dec 9, 2008, 11:57:22 AM12/9/08
to
On Dec 9, 9:28 am, MRAB <goo...@mrabarnett.plus.com> 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

Carl Banks

unread,
Dec 9, 2008, 1:20:27 PM12/9/08
to
On Dec 9, 7:48 am, Paul Boddie <p...@boddie.org.uk> wrote:
> On 9 Des, 14:24, Steven D'Aprano <st...@REMOVE-THIS-
>
> 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

Chris Mellon

unread,
Dec 9, 2008, 1:23:24 PM12/9/08
to pytho...@python.org

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.

MRAB

unread,
Dec 9, 2008, 1:40:03 PM12/9/08
to pytho...@python.org
Aaron Brady wrote:
> On Dec 9, 8:28 am, MRAB <goo...@mrabarnett.plus.com> 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.

Mel

unread,
Dec 9, 2008, 4:17:09 PM12/9/08
to
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.


Steven D'Aprano

unread,
Dec 9, 2008, 5:53:03 PM12/9/08
to
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

Steven D'Aprano

unread,
Dec 9, 2008, 6:00:48 PM12/9/08
to
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

Aaron Brady

unread,
Dec 10, 2008, 1:45:03 AM12/10/08
to
On Dec 9, 12:40 pm, MRAB <goo...@mrabarnett.plus.com> wrote:
> Aaron Brady wrote:
> > On Dec 9, 8:28 am, MRAB <goo...@mrabarnett.plus.com> 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.

Aaron Brady

unread,
Dec 10, 2008, 2:21:54 AM12/10/08
to
On Dec 9, 4:53 pm, Steven D'Aprano <st...@REMOVE-THIS-

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.

Paul Boddie

unread,
Dec 10, 2008, 6:43:26 AM12/10/08
to
On 10 Des, 00:00, Steven D'Aprano <st...@REMOVE-THIS-

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

Paul Boddie

unread,
Dec 10, 2008, 8:45:30 AM12/10/08
to
On 9 Des, 19:23, "Chris Mellon" <arka...@gmail.com> 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

MRAB

unread,
Dec 10, 2008, 9:57:58 AM12/10/08
to pytho...@python.org
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.

Bruno Desthuilliers

unread,
Dec 10, 2008, 10:51:42 AM12/10/08
to
Lie a écrit :
> On Dec 7, 2:38 am, "Warren DeLano" <war...@delsci.com> 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...

Patrick Mullen

unread,
Dec 10, 2008, 12:22:46 PM12/10/08
to MRAB, pytho...@python.org
> 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.

MRAB

unread,
Dec 10, 2008, 12:38:39 PM12/10/08
to pytho...@python.org
Patrick Mullen wrote:
> On Wed, Dec 10, 2008 at 6:57 AM, MRAB <goo...@mrabarnett.plus.com>
>> 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.

Patrick Mullen

unread,
Dec 10, 2008, 4:16:54 PM12/10/08
to pytho...@python.org
On Wed, Dec 10, 2008 at 11:57 AM, Benjamin Kaplan
<benjami...@case.edu> wrote:

>
>
> On Wed, Dec 10, 2008 at 12:22 PM, Patrick Mullen <saluk...@gmail.com>
> 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|identifier><colon>" 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".

0 new messages