py3k concerns. An example

[Paul McGuire]

On Apr 19, 4:42 am, Carl Banks <pavlovevide... at gmail.com> 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