"as" keyword woes

W

Warren DeLano

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

alex23

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

James Stroud

alex23 said:
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.
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.
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.
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
 
C

Carl Banks

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
 
C

Carl Banks

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
 
A

Albert Hopkins

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
 
C

Carl Banks

It's been a while so I can't remember, but it seems like "yield" was
dropped in to python relatively quickly in 2.2.  Was there a similar
outrage when "yield" became a keyword?

This is just one guy complaining. Yes, I'd imagine when "yield" and
"with" were made into keywords there was probably someone, somewhere
who complained about that, too.

I doubt there will much outrage over "as". It has been in the works
for eight years and six releases, after all. Anyone who was paying
attention wouldn't have been using "as" as an identifier. Among those
who weren't paying attention, anyone smart wouldn't have been using
"as" as an identifier because A) it is used as a syntactic element,
and even if it's not a keyword it's poor style to use it also as an
identifier, and B) you had to suspect sooner or later they would make
it into a real keyword.

Among those who were using "as" as an identifier, the vast majority
will simply do an interactive search-and-replace to fix it.

People like Warren here who have distributed codebases they can't
easily fix up, and who were neither smart nor informed enough to avoid
using "as", are a pretty tiny minority, I would guess.


Carl Banks
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top