On 27.06.12 15:44, Stefan Behnel wrote:
Christian Tismer, 27.06.2012 15:15:
print, function or not, is not important enough to enforce a rewrite
everywhere because of syntax error. That hides the real semantic
changes which _are_ important.
So what I would have done is to let it work in an imperfect way. People
then have the chance to rewrite with the print function, where it makes
sense. But old packages which need to be changed, only because they
have lots of
if DEBUG:
print xxx, yyy, ...
could just stay unchanged or migrated later after the real meat has
been properly tested etc.
Well, at least a SyntaxError makes it easy to find. And even if you don't
intend to use 2to3, you can still run it once to generate a patch for you
that only fixes up "print". In many cases, that will also make it work in
Py2 in such an "imperfect" way, either by doing the right thing already or
by printing out a tuple instead of a space separated string. If it's only
for debug output (which, as I said, would better be served by the logging
module), I can't see why that would be all that unacceptable.
Ok, here comes the real story:
I extracted a few files from the old PIL package and made the stuff that was
needed for my own little utility with a couple of monkey-patches, import
hooks etc. After quite some trouble, this worked unter python 2.6 and 2.7,
with the unchanged original PIL files.
And I was after that: abuse PIL without maintaining it!
Then I got real problems when trying to make it run under python 3.2,
and from then on I needed two sets of source files, mostly because of
the print mess.
Most other things were adjustable by monkey-patches, moving to the io
module etc. etc.
In the end, the only thing that required a real change of source code
that I could not circumvent was the indexing of bytes, which is giving
chars under python 2.x, but integers under 3.x.
At this point my hope to keep the unmodified PIL files died, although
without print, this would have been an isolated single 20 lines block
in the TiffImagePlugin only, instead of much more changes criss-cross over
several sources.
Anyway, I ended up with a port of the relevant PIL files to python 3
with some backward-compatible additions (for heaven's sake, at least
python 3 accepts the __future__ imports), so now I'm down to single
source files, but unfortunately changed files, and I have to track
changes in the future.
That battle was lost: I wanted the PIL files simply to be drop-ins,
without going to work on PIL, because then I would do a complete
rewrite after some discussion with the author.
That's why I was unhappy with py3's missing flexibility.
ciao -- Chris
--
Christian Tismer :^) <mailto:tis...@stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
work +49 173 24 18 776 mobile +49 173 24 18 776 fax n.a.
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
--
http://mail.python.org/mailman/listinfo/python-list
