Re: Multiple copies of timeoutsocket.py in Debian packages
Hi.
Thanks for your responses.
Jakub Wilk <jwilk@debian.org> writes:
> * Olivier Berger <olivier.berger@telecom-sudparis.eu>, 2014-01-28, 16:39:
>>A quick search on http://codesearch.debian.net reports many hits for
>>the timeoutsocket.py library.
>>
>>I think it would be better to have a distinct package, then (hence a
>>RFP: #736935).
>>
>>However I don't have a clue whether this is really used by these
>>packages, if multiple versions co-exist, etc. I haven't played with
>>sockets in Python yet.
>>
>>I'm tempted to think that it may even no longer be needed at all,
>>judging from http://bugs.python.org/issue555085 if the feature was
>>added to Python's standard library.
>
> Yeah, timeoutsocket.py looks like something that should have died a
> decade ago. In Python ≥ 2.3 you can set default timeout or a per-socket
> timeout without help of this library.
>
> planet-venus, python-feedvalidator and rawdog already use the proper
> Python interfaces, and only fall back to timeoutsocket when they are not
> available:
> http://sources.debian.net/src/python-feedvalidator/0~svn1022-2/feedvalidator/__init__.py#L8
> http://sources.debian.net/src/planet-venus/0~git9de2109-1/planet/spider.py#L378
> http://sources.debian.net/src/rawdog/2.13.dfsg.1-1/rawdoglib/feedparser.py#L103
>
I'm wondering, in similar cases, if there is anything that should be
done for these packages, like patching the code to remove the embedded
copy and get rid of the import check, since our Python versions in
Debian are recent enough ? This would eliminate uncertainty... or maybe
things should just be kept in the current state... Maybe that's not
worth the worry in general.
> plucker and spikeproxy would have to be ported to the “new” API.
>
I guess that would be worth a bug report, then ?
Best regards,
--
Olivier BERGER
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
Reply to: