On Apr 19, 4:42 am, Carl Banks <[EMAIL PROTECTED]> wrote: > > If you don't like Python 3, DON'T USE IT. >
I've read this position a number of times in this and related threads, and it overlooks one constituency of Python developers - those who develop and support modules for use by other Python users. As the supporter of pyparsing, I really can't just "not use" Py3 - ignoring Py3 means shutting out/holding back those of my users who do want to use it, and pretty much consigning my module to eventual dustbin status. Ideally, I can implement some form of cross-compatible code so that I need maintain only a single code base, and I have managed to do so on a number of fronts (with the help of Robert A. Clark): - add support for both __bool__ and __nonzero__ (__nonzero__ calls __bool__, so that upgrading to Py3 actually saves a function call) - convert isinstance(x,basestring) to isinstance(x,__BASESTRING__) and dynamically set __BASESTRING__ to basestring or str - similar treatment for sys.maxint/maxsize -> __MAX_INT__ I dodged a bullet when 3.0a3 added back in support for the 2.x form of "except" for exception handling. 3.0a2 only supported "except varname as ExceptionType:" and there was no way I could do this in a multi- version compatible way. My remaining hassle is print as function vs. print as statement. I provide a number of default diagnostic methods, and I have not fully gotten all to print nice - converting "print x" to "print (x)" is simple enough, and "print (x,y)" replaces "print x,y" well enough when running under Py3, but the same code in Py2.x now prints a tuple instead of a nice string like before. I will probably punt on the whole issue in the next release and just use sys.write.stdout/stderr throughout, and " ".join() the args (another function call!) before calling. I wasn't aware of the coming deprecation of '%' string interpolation, but at least it is deferred until 3.3, which does give me a few years I should think before I absolutely must address it. This is really not so much an issue for me as it is for my "customers." Pyparsing returns its parsed tokens using a class that is dict-like in behavior, but without extending dict (duck-typing at its finest!). I really like that my users can parse an expression and access any named fields directly and neatly in an interpolated string using "%(field_name)s". If this is removed, pyparsing will continue to work as-is, but I feel like a nice ease-of-access mode will have been lost to those who use it. Overall, I think I'm getting off pretty easy, but then pyparsing is a small module with very limited use of the standard lib. I can imagine that maintainers of larger libraries are having some serious fits trying to support both versions with a single code base. And as much as we all love Python-the-language, language features alone do not help a language and its community of users to grow and proliferate. I think most would agree that it is the cornucopia of libraries that really make Python an environment for developing production applications. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
