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 -- http://mail.python.org/mailman/listinfo/python-list