On 10/09/12 00:51, Brian Crowell wrote:
Yes, that seems to me to be the main trouble. Anything done to the
Python source will break compatibility with code before 2.6. I'm sure
that's why it looks like PIL has been ported to Python 3 several
times, but none of them stuck.
How do other developers feel about that? Maybe letting old PIL 1.1.7
take care of anyone using 2.5/2.6 or older, and focusing on 2.6/2.7
and up? Or perhaps maintaining a separate branch with Python 3 code?
I don't think support for older versions is necessarily that important.
One thing I do here is support Python software for the Hubble Space Telescope.
It means I get a lot of support tickets from astronomers at other institutions.
These are people who are not interested in programming, except for the minimum
they need to get their job done. They want to use whatever python they have,
and if I tell them to upgrade 20 different things they are not happy.
I haven't seen a support ticket from any python 2.5 users for a long time now. There are
still some linux distributions that use python 2.6. I don't think those distributions
are looking for a replacement for PIL. So, I think python 2.6 is relatively unimportant
and python 2.5 support is a serious "don't care" at this point.
If you were to support python 3 only, you would not make any difference to
python 2 users. They would continue to use the latest PIL that was released
about 3 years ago. There would just be a python 3 version available. Python 3
has two major problems: 1) it is incompatible with python 2, and 2) too many
packaged don't exist for that. If you make a contribution to solving #2, that
is a net improvement.
The question, then is python 2.7.
The problem you have is not technical. It is marketing. Do you propose to try
to replace PIL with your derivative package? If so, you have to get people to
know about it. For example, Pillow (a fork of PIL) is almost 2 years old, but
I just found out about it a few months ago.
So, how do you get people to know about and use your package?
- promote it - I can't use it if I don't know about it. (b.t.w. One way to promote your
package: If you fix problems that people frequently have with PIL, then you can announce
it on mailing lists, forums, stackoverflow, etc. It is not spam if you are saying
"I know a package that fixes your problem".)
- include support for python 2.7 (and maybe 2.6 if it is easy). If I can use it in my
python 2.7 environment, then it is not "just some thing that I don't care about
because I don't use python 3". Make your package attractive, and I can have just
one package for both my existing python 2.7 environment and my prototype python 3
environment. Someday, when I might want python 3, I will remember your package.
- add new capabilities and fix old bugs, so that I have some reason to switch
to your package even though I already have PIL installed. For example, I did
not find gamma correction in the latest PIL; if you have one, maybe your
package is more interesting to me.
- but remain plug-compatible with the old PIL, so everything just works
- be willing to support the package in the long term; if you make a python 3
port and then abandon it, it is just another of thousands of abandoned packages.
Maybe you can make an alliance with all those other people who tried python 3 ports.
They've done at least some of the work, and you could work together to promote whatever
you collectively come up with. But don't let forming the alliance be an obstacle to
doing anything. If you spend all your time arguing, you gain nothing. Also, if you
spend all your time saying "I don't know - what do YOU think?" you also don't
get anywhere.
Mark S.
_______________________________________________
Image-SIG maillist - Image-SIG@python.org
http://mail.python.org/mailman/listinfo/image-sig
