"as" keyword woes

[M.-A. Lemburg]

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