Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PyClean installation

64 views
Skip to first unread message

Julien ÉLIE

unread,
Dec 13, 2015, 4:00:15 PM12/13/15
to
Hi,

At last I'm having a look at the installation of PyClean
https://github.com/crooks/PyClean

I noted two portability issues:


* File "/usr/lib/python2.4/site-packages/pyclean/pyclean.py", line 149
class Binary():
^
SyntaxError: invalid syntax

Changing
class Binary():
to
class Binary:
fixes the issue. That syntax should also be enforced to other "class
xxx():" in pyclean.py.



* File "/usr/lib/python2.4/site-packages/pyclean/pyclean.py", line 264
bad_files = {f: 0 for f in bad_file_list}
^
SyntaxError: invalid syntax

Dict comprehensions are only available in Python 2.7 upwards. I suggest
to use the legacy syntax:

bad_files = dict((f, 0) for f in bad_file_list)




Well, after these two fixes for older versions of Python, I do not
manage to run pyclean.py.

Note that the install path is different from the one mentioned in INSTALL:
"Assuming the standard locations have been used, the following
commands can be issued:-

cd ~news/bin/filter
ln -s /usr/local/lib/python2.x/dist-packages/pyclean/pyclean.py
filter_innd.py
"

I have /usr/lib/python2.4/site-packages/pyclean/pyclean.py instead of
dist-packages.

INN.py and filter_innd.py are in "~news/bin/filter".
I have set PYTHONPATH to ".:~news/bin/filter" for the news user.

Otherwise, I have:

%python pyclean.py
Traceback (most recent call last):
File "pyclean.py", line 3, in ?
import INN
ImportError: No module named INN


But with PYTHONPATH set to ".:~news/bin/filter", I have:

% python filter_innd.py
Traceback (most recent call last):
File "filter_innd.py", line 4, in ?
from pyclean.Config import config
File "/usr/lib/python2.4/site-packages/pyclean/pyclean.py", line 4, in ?
from pyclean.Config import config
ImportError: No module named Config

and naturally:

% ctlinnd reload filter.python "PyClean initial load"
ctlinnd: Failed to reload filter_innd.py



I do not understand why pyclean.Config is not found.
Especially, when I have:

% python -c "import sys; print sys.path"
['', '/home/news', '/home/news/bin/filter', '/usr/lib/python24.zip',
'/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2',
'/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload',
'/usr/local/lib/python2.4/site-packages',
'/usr/lib/python2.4/site-packages', '/var/lib/python-support/python2.4']

% python -c "from pyclean.Config import config ; print 'OK'"
OK

So the import seems to work fine...


Steve, do you have any recommendation usage related to paths to make it
work? Is it the right thing I am doing to install PyClean?

--
Julien ÉLIE

« – Il est parti comme il est venu…
– Il ne faisait que passer… » (Astérix)

Steve Crook

unread,
Jan 10, 2016, 4:32:05 PM1/10/16
to
On Sun, 13 Dec 2015 22:00:13 +0100, Julien ÉLIE wrote in
Message-Id: <n4km8u$1ra$1...@news.trigofacile.com>:

> Hi,
>
> At last I'm having a look at the installation of PyClean
> https://github.com/crooks/PyClean

Hi Julien,

Apologies for not seeing this sooner, I'd accidentally unsubscribed from
the Newsgroup.

> I noted two portability issues:
>
>
> * File "/usr/lib/python2.4/site-packages/pyclean/pyclean.py", line 149
> class Binary():
> ^
> SyntaxError: invalid syntax
>
> Changing
> class Binary():
> to
> class Binary:
> fixes the issue. That syntax should also be enforced to other "class
> xxx():" in pyclean.py.
Thanks, that was easily fixed and seems to have no impact on later
versions.

> * File "/usr/lib/python2.4/site-packages/pyclean/pyclean.py", line 264
> bad_files = {f: 0 for f in bad_file_list}
> ^
> SyntaxError: invalid syntax
>
> Dict comprehensions are only available in Python 2.7 upwards. I suggest
> to use the legacy syntax:
>
> bad_files = dict((f, 0) for f in bad_file_list)
Also fixed and tested against 2.7.9.

> Well, after these two fixes for older versions of Python, I do not
> manage to run pyclean.py.
>
> Note that the install path is different from the one mentioned in INSTALL:
> "Assuming the standard locations have been used, the following
> commands can be issued:-
>
> cd ~news/bin/filter
> ln -s /usr/local/lib/python2.x/dist-packages/pyclean/pyclean.py
> filter_innd.py
> "
>
> I have /usr/lib/python2.4/site-packages/pyclean/pyclean.py instead of
> dist-packages.

I think dist-packages is a Debian thing. As I always work on Debian, I
hadn't appreciated the difference from standard.

> INN.py and filter_innd.py are in "~news/bin/filter".
> I have set PYTHONPATH to ".:~news/bin/filter" for the news user.
>
> Otherwise, I have:
>
> %python pyclean.py
> Traceback (most recent call last):
> File "pyclean.py", line 3, in ?
> import INN
> ImportError: No module named INN
Yes, you'll need the INN.py stub if Pyclean isn't not being initiated
through INN. This isn't really a bug, but it's probably worth my adding
a note to the INSTALL.

> But with PYTHONPATH set to ".:~news/bin/filter", I have:
>
> % python filter_innd.py
> Traceback (most recent call last):
> File "filter_innd.py", line 4, in ?
> from pyclean.Config import config
> File "/usr/lib/python2.4/site-packages/pyclean/pyclean.py", line 4, in ?
> from pyclean.Config import config
> ImportError: No module named Config
This is where the fun really starts! Python < 2.6 made a poor job of
handling packages with relative links to modules. I figured out how to
fix it but the fix then breaks versions >= 2.6. In the end, I think the
best solution is to merge all the packaged files into the single
pyclean.py file. This has an added advantage that the pyclean.py file
can now be put directly into the ~news/bin/filter directory (either with
a symlink or renamed to filter_innd.py). This change has now been
commited to the github repository.

Next I installed Python2.4 and tried to test against it. There are a
number of libraries that didn't exist back then, including:

hashlib
email.utils (was email.Utils)
collections (defaultdict)

These were relatively easy to workaround.

I've got the new code running on my server now but it's using
python-2.7.9. There may be runtime issues with older Pythons so I'll
create a test platform but it will take some more time.

--
What shall we use
To fill the empty spaces
Where we used to talk?

Steve Crook

unread,
Jan 14, 2016, 7:14:51 AM1/14/16
to
On Sun, 10 Jan 2016 21:32:05 -0000 (UTC), Steve Crook wrote in
Message-Id: <slrnn95jel...@fleegle.mixmin.net>:

> This is where the fun really starts! Python < 2.6 made a poor job of
> handling packages with relative links to modules. I figured out how to
> fix it but the fix then breaks versions >= 2.6. In the end, I think the
> best solution is to merge all the packaged files into the single
> pyclean.py file. This has an added advantage that the pyclean.py file
> can now be put directly into the ~news/bin/filter directory (either with
> a symlink or renamed to filter_innd.py). This change has now been
> commited to the github repository.
>
> Next I installed Python2.4 and tried to test against it. There are a
> number of libraries that didn't exist back then, including:
>
> hashlib
> email.utils (was email.Utils)
> collections (defaultdict)
>
> These were relatively easy to workaround.
>
> I've got the new code running on my server now but it's using
> python-2.7.9. There may be runtime issues with older Pythons so I'll
> create a test platform but it will take some more time.

Hi Julien,

I've now tested the revised PyClean and it's been stable for a few days.
Would you mind downloading it and trying again? The modules are now
merged into a single file, pyclean.py so you don't need to install it
using the install script, it can be placed directly into the
~news/bin/filter directory and renamed as filter_innd.py (or symlinked).

Best wishes,
Steve

Julien ÉLIE

unread,
Jan 14, 2016, 3:45:11 PM1/14/16
to
Hi Steve,

> I've now tested the revised PyClean and it's been stable for a few days.
> Would you mind downloading it and trying again? The modules are now
> merged into a single file, pyclean.py so you don't need to install it
> using the install script, it can be placed directly into the
> ~news/bin/filter directory and renamed as filter_innd.py (or symlinked).

Thanks for your new version. It is indeed far easier to install!

* cd ~/bin/filter
* wget --no-check-certificate
https://raw.githubusercontent.com/crooks/PyClean/master/pyclean/pyclean.py
* mv pyclean.py filter_innd.py
* ctlinnd reload filter.python "PyClean initial load"

And it worked!


I have deactivated Perl filtering to see how Python filtering performs.
Too bad INN still does not implement a filter_stats function for Python;
it would allow stats from the Python filter in response to "ctlinnd
mode". We have one for Perl:

Perl filter stats: Pass: 43633 Reject: 1435 Refuse: 0 MD5: 16 PHL:
53 PHN: 67 PHR: 0 FSL: 31



Hmmm, looking at ~/pyclean/log/traceback, I see:

Traceback (most recent call last):
File "/home/news/bin/filter/filter_innd.py", line 302, in filter_art
return self.pyfilter.filter(art)
File "/home/news/bin/filter/filter_innd.py", line 808, in filter
if self.emp_phn.add(fodder + ngs):
File "/home/news/bin/filter/filter_innd.py", line 1180, in add
h = md5(content).digest()
TypeError: 'module' object is not callable


Do you know how to fix that?

--
Julien ÉLIE

« Veni, uidi, et je n'en crois pas mes yeux ! » (César)

Julien ÉLIE

unread,
Jan 14, 2016, 3:52:34 PM1/14/16
to
Hi Steve,

>> bad_files = dict((f, 0) for f in bad_file_list)
> Also fixed and tested against 2.7.9.

Thanks!


>> ImportError: No module named INN
> Yes, you'll need the INN.py stub if Pyclean isn't not being initiated
> through INN. This isn't really a bug, but it's probably worth my adding
> a note to the INSTALL.

OK.


> In the end, I think the
> best solution is to merge all the packaged files into the single
> pyclean.py file. This has an added advantage that the pyclean.py file
> can now be put directly into the ~news/bin/filter directory (either with
> a symlink or renamed to filter_innd.py). This change has now been
> commited to the github repository.

That's indeed a great advantage. I am totally in favour of that change.


> Next I installed Python2.4 and tried to test against it.

Many thanks, Steve.

--
Julien ÉLIE

« As promised, here's the patch to do this. Not only is it good (it
compiles), but it is perfect (it boots). Up 9 minutes so far without
problems. » (Richard Gooch on linux-kernel)

Steve Crook

unread,
Jan 14, 2016, 5:18:14 PM1/14/16
to
On Thu, 14 Jan 2016 21:45:10 +0100, Julien ÉLIE wrote in
Message-Id: <n791cm$14v$1...@news.trigofacile.com>:

> Hmmm, looking at ~/pyclean/log/traceback, I see:
>
> Traceback (most recent call last):
> File "/home/news/bin/filter/filter_innd.py", line 302, in filter_art
> return self.pyfilter.filter(art)
> File "/home/news/bin/filter/filter_innd.py", line 808, in filter
> if self.emp_phn.add(fodder + ngs):
> File "/home/news/bin/filter/filter_innd.py", line 1180, in add
> h = md5(content).digest()
> TypeError: 'module' object is not callable
>
>
> Do you know how to fix that?

Hi Julien,

Thanks again for taking the time to look at this. The error is caused
by a bad import against Python 2.4. The fix is:

crooks@fleegle:~/pyclean-git/pyclean$ git diff
diff --git a/pyclean/pyclean.py b/pyclean/pyclean.py
index eaaf1be..d8f8110 100644
--- a/pyclean/pyclean.py
+++ b/pyclean/pyclean.py
@@ -23,7 +23,7 @@ except ImportError:
try:
from hashlib import md5
except ImportError:
- import md5
+ from md5 import md5

# First, define some high-level date/time functions
def now():

Steve Crook

unread,
Jan 14, 2016, 5:25:45 PM1/14/16
to
On Thu, 14 Jan 2016 21:45:10 +0100, Julien ÉLIE wrote in
Message-Id: <n791cm$14v$1...@news.trigofacile.com>:

> I have deactivated Perl filtering to see how Python filtering performs.
> Too bad INN still does not implement a filter_stats function for Python;
> it would allow stats from the Python filter in response to "ctlinnd
> mode". We have one for Perl:
>
> Perl filter stats: Pass: 43633 Reject: 1435 Refuse: 0 MD5: 16 PHL:
> 53 PHN: 67 PHR: 0 FSL: 31

There are some stats logged hourly in the pyclean.log file:

2016-01-14 00:29:38 INFO emp_body: size=948, processed=502,
accepted=441, rejected=57
2016-01-14 00:29:38 INFO emp_fsl: size=1059, processed=502,
accepted=502, rejected=0
2016-01-14 00:29:38 INFO emp.phl: size=731, processed=364,
accepted=364, rejected=0
2016-01-14 00:29:38 INFO emp_phn: size=291, processed=357,
accepted=357,rejected=0
2016-01-14 00:29:38 INFO emp_ihn: size=2, processed=0, accepted=0,
rejected=0

I should probably add a totals counter for articles processed, accepted,
rejected.

Julien ÉLIE

unread,
Jan 15, 2016, 3:02:50 PM1/15/16
to
Hi Steve,

> The error is caused
> by a bad import against Python 2.4. The fix is:

OK, applied.
I no longer see the error.


Is the following warning normal?
I thought pyclean.cfg was not mandatory (INSTALL says it is needed only
to tweak the behaviour of PyClean):

2016-01-15 00:55:41 INFO Reloading config file:
/home/news/pyclean/etc/pyclean.cfg
2016-01-15 00:55:41 WARNING /home/news/pyclean/etc/pyclean.cfg: File not
found

--
Julien ÉLIE

« Si ça n'a pas fait boum, c'est peut-être le succès ? »
(Astérix)

Julien ÉLIE

unread,
Jan 15, 2016, 3:07:20 PM1/15/16
to
Hi Steve,

>> Perl filter stats: Pass: 43633 Reject: 1435 Refuse: 0 MD5: 16 PHL:
>> 53 PHN: 67 PHR: 0 FSL: 31
>
> There are some stats logged hourly in the pyclean.log file:
>
> 2016-01-14 00:29:38 INFO emp_body: size=948, processed=502,
> accepted=441, rejected=57

Yes, I see them in my logs.
They weren't present yesterday because I still had not been running
PyClean for an hour!


> I should probably add a totals counter for articles processed, accepted,
> rejected.

That would be helpful, indeed. A counter that keeps incrementing, until
INN is restarted. (The same way as how Cleanfeed stats work.)

Steve Crook

unread,
Jan 16, 2016, 8:23:59 AM1/16/16
to
On Fri, 15 Jan 2016 21:02:49 +0100, Julien ÉLIE wrote in
Message-Id: <n7bj99$2es$1...@news.trigofacile.com>:

> Hi Steve,
>
>> The error is caused
>> by a bad import against Python 2.4. The fix is:
>
> OK, applied.
> I no longer see the error.
Thanks, I've commited the change now.

> Is the following warning normal?
> I thought pyclean.cfg was not mandatory (INSTALL says it is needed only
> to tweak the behaviour of PyClean):
>
> 2016-01-15 00:55:41 INFO Reloading config file:
> /home/news/pyclean/etc/pyclean.cfg
> 2016-01-15 00:55:41 WARNING /home/news/pyclean/etc/pyclean.cfg: File not
> found
I've changed that to an INFO and improved the logged message. The
config file is optional and the defaults work in most cases.

Julien ÉLIE

unread,
Jan 31, 2016, 9:50:23 AM1/31/16
to
Hi Steve,

>> 2016-01-15 00:55:41 WARNING /home/news/pyclean/etc/pyclean.cfg: File not
>> found
> I've changed that to an INFO and improved the logged message. The
> config file is optional and the defaults work in most cases.

Thanks.
PyClean has behaved fine these last two weeks.


I have two remarks:

* couldn't the body_fuzzy parameter use the "true" value by default
instead of "yes"? All the other boolean parameters use "true"/"false".

I know it is the same for ConfigParser; it would just be more coherent.



* couldn't the exclusion lists be parametrable?
For instance, it could be useful to allow a change of the currently
hard-coded variable in PyClean:
html_allowed = ['^pgsql\.', '^relcom\.', '^gmane', 'microsoft',
'^mailing\.']

One may add local newsgroups, or change the default list.

Steve Crook

unread,
Feb 2, 2016, 10:57:34 AM2/2/16
to
On Sun, 31 Jan 2016 15:50:21 +0100, Julien ÉLIE wrote in
Message-Id: <n8l6ve$psu$1...@news.trigofacile.com>:

> Hi Steve,
>
>>> 2016-01-15 00:55:41 WARNING /home/news/pyclean/etc/pyclean.cfg: File not
>>> found
>> I've changed that to an INFO and improved the logged message. The
>> config file is optional and the defaults work in most cases.
>
> Thanks.
> PyClean has behaved fine these last two weeks.

Hi Julien,

Good to hear it's worked for you!

> I have two remarks:
>
> * couldn't the body_fuzzy parameter use the "true" value by default
> instead of "yes"? All the other boolean parameters use "true"/"false".
I've changed it in the default config from "yes" to "true". They are
interchangable within the parser so it was just a text change.

> I know it is the same for ConfigParser; it would just be more coherent.
Agreed.

> * couldn't the exclusion lists be parametrable?
> For instance, it could be useful to allow a change of the currently
> hard-coded variable in PyClean:
> html_allowed = ['^pgsql\.', '^relcom\.', '^gmane', 'microsoft',
> '^mailing\.']
>
> One may add local newsgroups, or change the default list.

Yes, I think this could be done without too much effort. The Regex file
parser within PyClean already does this for the bad_* style files stored
in pyclean/etc. I'll take a look at it over the weekend if the weather
keeps me in. This being England, that's a fairly sure bet. :)

Julien ÉLIE

unread,
Feb 3, 2016, 4:03:12 PM2/3/16
to
Steve,

> Yes, I think this could be done without too much effort. The Regex file
> parser within PyClean already does this for the bad_* style files stored
> in pyclean/etc. I'll take a look at it over the weekend if the weather
> keeps me in. This being England, that's a fairly sure bet. :)

Thanks for the change for body_fuzzy, and also the future improvement in
handling local exclusion lists.
Enjoy your week-end, be it sunny or rainy!

--
Julien ÉLIE

« The most effective way to remember your wife's birthday is to forget
it once… » (Nash)

Julien ÉLIE

unread,
May 28, 2016, 12:20:28 PM5/28/16
to
Hi Steve,

PyClean has been working perfectly for a few months, so that's pretty
good news.


> Next I installed Python2.4 and tried to test against it. There are a
> number of libraries that didn't exist back then

Also, datetime.strptime was added in Python 2.5; only time.strptime
exists in Python 2.4.
Strange that none of us remarked it when we tested that at the beginning
of the year. I bet we did not totally restart INN. I only noticed that
yesterday when updating INN.

Here is a patch that fixes the issue:


--- pyclean.py 2016-05-28 16:40:26.000000000 +0200
+++ ../../bin/filter/filter_innd.py 2016-05-28 16:37:56.000000000 +0200
@@ -10,6 +10,7 @@
import logging.handlers
import shelve
import sys
+import time
import datetime
import ConfigParser

@@ -38,7 +38,8 @@

def dateobj(datestr):
"""Take a string formated date (yyyymmdd) and return a datetime
object."""
- return datetime.datetime.strptime(datestr, '%Y%m%d')
+ return datetime.datetime(*(time.strptime(datestr, '%Y%m%d')[0:6]))
+ #return datetime.datetime.strptime(datestr, '%Y%m%d')


def nowstamp():



Have a nice day,

--
Julien ÉLIE

« – Ce n'était pas ma question.
– C'était p'têt pas vot'question, oui, mais c'est ma
réponse ! » (Georges Marchais répondant à Alain Duhamel)

Steve Crook

unread,
May 29, 2016, 6:01:44 AM5/29/16
to
On Sat, 28 May 2016 18:20:27 +0200, Julien ÉLIE wrote in
Message-Id: <nicggb$hq4$1...@news.trigofacile.com>:

> Hi Steve,
>
> PyClean has been working perfectly for a few months, so that's pretty
> good news.
Excellent, I'm pleased to hear it's working for you.

>> Next I installed Python2.4 and tried to test against it. There are a
>> number of libraries that didn't exist back then
>
> Also, datetime.strptime was added in Python 2.5; only time.strptime
> exists in Python 2.4.
> Strange that none of us remarked it when we tested that at the beginning
> of the year. I bet we did not totally restart INN. I only noticed that
> yesterday when updating INN.

Thanks, I've applied that now.

Is there a reason why we maintain Python 2.4 compatibility rather than
any other specific version? v2.4 was released in 2004 so it seems
unlikely to still be packaged in any stable Linux releases.

On a vaguely related topic, I'm seeing little enthusiasm for migrating
projects to Python 3.x. It was announced in 2014 that v2.7 was the last
of the 2.x series. Perhaps projects are re-platforming instead of
upgrading?

Kevin Bowling

unread,
May 30, 2016, 10:25:23 PM5/30/16
to
On 05/29/16 03:01 AM, Steve Crook wrote:
> On Sat, 28 May 2016 18:20:27 +0200, Julien ÉLIE wrote in
> Message-Id: <nicggb$hq4$1...@news.trigofacile.com>:
>
>> Hi Steve,
>>
>> PyClean has been working perfectly for a few months, so that's pretty
>> good news.
> Excellent, I'm pleased to hear it's working for you.
>
>>> Next I installed Python2.4 and tried to test against it. There are a
>>> number of libraries that didn't exist back then
>>
>> Also, datetime.strptime was added in Python 2.5; only time.strptime
>> exists in Python 2.4.
>> Strange that none of us remarked it when we tested that at the beginning
>> of the year. I bet we did not totally restart INN. I only noticed that
>> yesterday when updating INN.
>
> Thanks, I've applied that now.
>
> Is there a reason why we maintain Python 2.4 compatibility rather than
> any other specific version? v2.4 was released in 2004 so it seems
> unlikely to still be packaged in any stable Linux releases.

As usual RedHat's fault for their zombie distros. Python 2.4 is the
default '/usr/bin/env python' although you can install python 2.6
officially to '/usr/bin/env python26'.

> On a vaguely related topic, I'm seeing little enthusiasm for migrating
> projects to Python 3.x. It was announced in 2014 that v2.7 was the last
> of the 2.x series. Perhaps projects are re-platforming instead of
> upgrading?

Mostly Python 2.7 is "good enough" for a lot of users. Python 3 is
seeing an uptick, but there has been a chicken and egg problem with some
common libraries that first had to be cleared up. PyClean should work
well enough on both versions with one of the mechanical translators.

Regards,
Kevin

Julien ÉLIE

unread,
May 31, 2016, 4:01:23 PM5/31/16
to
Hi Steve,

> Is there a reason why we maintain Python 2.4 compatibility rather than
> any other specific version? v2.4 was released in 2004 so it seems
> unlikely to still be packaged in any stable Linux releases.

People do not always run recent distributions (either at home or at work).
If we have to chose a specific version, maybe it could be Python 2.2
because INN requires at least that version to build (distutils.sysconfig
is shipped with Python 2.2). But of course you are free to say PyClean
has stricter requirements!


> On a vaguely related topic, I'm seeing little enthusiasm for migrating
> projects to Python 3.x. It was announced in 2014 that v2.7 was the last
> of the 2.x series. Perhaps projects are re-platforming instead of
> upgrading?

As Python 2.7 is still maintained (EOL in 2020), I bet people do not see
any urge to migrate!

I wonder how Perl 6 will handle the migration... Perl 5 development
keeps being very active.

--
Julien ÉLIE

« – Gaaaaarde à vous !
– Oui ! Prenez garde à vous, Romains ! » (Astérix)

Russ Allbery

unread,
May 31, 2016, 4:21:47 PM5/31/16
to
Julien ÉLIE <iul...@nom-de-mon-site.com.invalid> writes:

> I wonder how Perl 6 will handle the migration... Perl 5 development
> keeps being very active.

My impression is that the Perl community collectively gave up on Perl 6
being the next version of Perl in any normal sense, and are basically
treating Perl 6 as a separate language from Perl 5 that's being developed
in parallel.

--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.

Steve Crook

unread,
Jun 2, 2016, 4:24:30 AM6/2/16
to
On Mon, 30 May 2016 19:25:22 -0700, Kevin Bowling wrote in
Message-Id: <niismi$2uq5$1...@csiph.com>:

>> Is there a reason why we maintain Python 2.4 compatibility rather than
>> any other specific version? v2.4 was released in 2004 so it seems
>> unlikely to still be packaged in any stable Linux releases.
>
> As usual RedHat's fault for their zombie distros. Python 2.4 is the
> default '/usr/bin/env python' although you can install python 2.6
> officially to '/usr/bin/env python26'.
>
>> On a vaguely related topic, I'm seeing little enthusiasm for migrating
>> projects to Python 3.x. It was announced in 2014 that v2.7 was the last
>> of the 2.x series. Perhaps projects are re-platforming instead of
>> upgrading?
>
> Mostly Python 2.7 is "good enough" for a lot of users. Python 3 is
> seeing an uptick, but there has been a chicken and egg problem with some
> common libraries that first had to be cleared up. PyClean should work
> well enough on both versions with one of the mechanical translators.

Thanks Kevin, I might run 2to3 on PyClean and see how cleanly it
translates. I still get the feeling that most distros are shipping 2.x
by default so I'm not really in any rush to migrate it.

Steve Crook

unread,
Jun 2, 2016, 4:33:30 AM6/2/16
to
On Tue, 31 May 2016 22:01:21 +0200, Julien ÉLIE wrote in
Message-Id: <nikqii$oi2$1...@news.trigofacile.com>:

> Hi Steve,
>
>> Is there a reason why we maintain Python 2.4 compatibility rather than
>> any other specific version? v2.4 was released in 2004 so it seems
>> unlikely to still be packaged in any stable Linux releases.
>
> People do not always run recent distributions (either at home or at work).
> If we have to chose a specific version, maybe it could be Python 2.2
> because INN requires at least that version to build (distutils.sysconfig
> is shipped with Python 2.2). But of course you are free to say PyClean
> has stricter requirements!

Hi Julian,

I'm happy to stick with 2.4 for now. PyClean only required minor tweaks
for so it's not an issue. I was just interested in why 2.4
compatibility was chosen over 2.2 or 2.6 (for example).

>> On a vaguely related topic, I'm seeing little enthusiasm for migrating
>> projects to Python 3.x. It was announced in 2014 that v2.7 was the last
>> of the 2.x series. Perhaps projects are re-platforming instead of
>> upgrading?
>
> As Python 2.7 is still maintained (EOL in 2020), I bet people do not see
> any urge to migrate!
>
> I wonder how Perl 6 will handle the migration... Perl 5 development
> keeps being very active.

I haven't written anything new in Perl for many years now. Perhaps I'm
being unfair to Perl but there always seems to be a more appealing
option!

Julien ÉLIE

unread,
Jun 2, 2016, 3:24:48 PM6/2/16
to
Hi Steve,

>>> Is there a reason why we maintain Python 2.4 compatibility rather than
>>> any other specific version? v2.4 was released in 2004 so it seems
>>> unlikely to still be packaged in any stable Linux releases.
>>
>> People do not always run recent distributions (either at home or at work).
>> If we have to chose a specific version, maybe it could be Python 2.2
>> because INN requires at least that version to build (distutils.sysconfig
>> is shipped with Python 2.2). But of course you are free to say PyClean
>> has stricter requirements!
>
> I'm happy to stick with 2.4 for now. PyClean only required minor tweaks
> for so it's not an issue. I was just interested in why 2.4
> compatibility was chosen over 2.2 or 2.6 (for example).

Because 2.4 is the average of 2.2 and 2.6.
Because it is 42 when read from right to left.
Because my news server is still running Debian Etch, whose default
Python version is 2.4, and I keep postponing an upgrade to another
hardware. That's why I mentioned the few tweaks that needed being done
for 2.4 :)
0 new messages