py3k concerns. An example

[Paul McGuire]

On Apr 24, 9:21 am, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> > Again, to me, this is a non-issue because I've been able to create a
> > cross-version compatible single codebase for pyparsing.  But it was a
> > bit dicey there for a while, and I think other module developers/
> > maintainers may not be so lucky.
>
> I'm more optimistic. I tried it for Django, and while the port is not
> complete, it goes really well and supports "basic" operations (i.e.
> the Django tutorial).
>
> Based on your experience, and other reports, I think there is a fair
> chance that you can support a wide range of versions (2.x and 3.x)
> from a single code base for most projects.
>
> > - create (if possible) single cross-version compatible code
> > - forego support of 3.0 users
> > - discontinue pre-2.6 support for future versions of their module
> > - maintain dual codebase
>
> One needs to consider the drawbacks in each case; for the single
> codebase approach, the drawback probably is that readability
> suffers, and the need for testing increases (but it does always
> if you support multiple targets). It also requires expertise to
> create such cross-version code in the first place, but that's
> "just" a learning issue (i.e. you have to keep the rules in mind
> that you want to follow).
>
> Regards,
> Martin

Martin --

Well, my concerns about 3.0 continue to be founded.  Up until now I
have been just reading "What's New" docs, and relying on input from
others as to what changes I will have to make.  Yesterday I downloaded
and installed 3.0a5, and it is clear that there is *no* way to have a
single code base for any but the most trivial module.

The biggest sticking point is the incompatibility of "except" syntax.
Apparently the promise of syntax compatibility in the 3.0a4 docs was
an overstatement.  Syntax can't be conditionalized out with "if
version >= 3:" type code, so I must have separate Python 2.x and
Python 3.x codebases, as will anyone whose modules include exception
handlers.

I also tripped over the conversion from "<iterator>.next()" to
"next(<iterator>)".  Fortunately, this only occurs in my test cases,
so my runtime module will not be affected by extra conditional
testing, just to pick the right code form for the particular Python
version that is running.

Conversion of print from statement to function is definitely more
painful than I thought it would be.  Again, I am fortunate that this
largely affects only my test code, with only minimal impact on my
runtime module.

I continue to struggle with some of the refactoring done in references
to func.func_code, im_self, etc. changing to __code__, __self__, and
so on.  There is a bit of code in Pyparsing that normalizes user
callbacks to a standard call using 3 arguments, and I have to
compensate for functions that have self args, or are callables.  I see
that there is some movement to "get rid of bound methods," but I don't
fully understand how this will be done, nor how I will adjust my code
to compensate.

In fact, I will probably set this effort aside for now, so as to avoid
converting/conditionalizing code to alpha versions of Python, and
having to change them again for later alphas or the final release.

By the way Martin, your work on 2to3 was especially helpful in this
effort - thank you!

In summary, I am adjusting my plans for future support of Python
versions in pyparsing.  As of a pyparsing release some time after
August, I will only support Python 3.0 versions with any new features
or bugfixes, and the pyparsing version that is compatible with Python
2.x will be frozen.

-- Paul