should Debian's Python cache module locations for import statments?
Hi,
the other day I asked myself why calendarserver (written in python using
twisted) takes ages to start when booting my laptop.
A measurable part of this is Python looking for modules. As the Debian
OS pretty much knows what modules are in /usr/lib/python2.5 and friends,
maybe Debian's Python should use that information, at least when called
from scripts in /usr/{s,}bin?
To add some numbers: For me (badly measured) fairly primitive caching
seems to reduce
python -c import zope.interface
from 5.5 to 2.5 seconds.[1]
Kind regards
T.
1. http://vman.de/debian/python-import-lookup-cache/
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: should Debian's Python cache module locations for import statments?
Thomas Viehmann wrote: ... Unfortunately python -mfoo -c ... is bogus without adding the proper calls. As such the speedup was also bogus and is only from 5.5 to 3.2 seconds or some such. Hooray for testing after the final cleanups. :) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug #503879: RFP: python-zanshin -- twisted-style caldav library
Maybe someone here likes python modules: Severity: wishlist Package: wnpp Package name: python-zanshin Version : 0.1 Upstream Author : OSAF / Grant Baillie URL : http://chandlerproject.org/Projects/ZanshinProject License : MIT Programming Lang: Python Description : python modules to access caldav servers Apparently there is no python module for talking to caldav servers in Debian. This one here has been developed for use with Chandler, but it seems to be a good fit with anything using python-twisted. I would appreciate if someone could package it, possibly with the Debian Python Modules Team. RFP is Bug #503879. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: handling /usr/local/lib/python2.x/site-packages in sys.path
Matthias Klose wrote: - add an env var to not include /usr/local/lib/python2.x/site-packages when the env var is set. Keeps standard behaviour without modifications and allows people to remove it from sys.path. But requires the user to know about that option. I would much prefer this. Debian users with local (=unpackaged) packages are probably much more common than Debian users with (=unpackaged) versions of all python, and I would rather reasonably support those than leaving them in the cold. Quite frankly, installing stuff that is also present in the system under user local is a recipe for disaster (also happens with libraries) and rather hard to cater for. - add another path (e.g. /usr/local/python/lib2.x/site-packages), and remove the /usr/local/lib/python2.x/site-packages path after the next release. Does provide an upgrade path, but doesn't solve the probem immediately. No. Let's not break stuff for people that use the software in Debian that they got from Debian. Quite frankly, the use case seems a bit of bad practice. Installing to /usr/local software to compete with that in /usr leads to all sorts of breakage where one doesn't expect it and if python.org needs people to install experimental versions they should either recommend chroots / test machines or provide packages. Anyone capable of installing a local version of python is also able to run debootstrap to create a chroot. Kind regards T. (who used to maintain a set of libraries where local installations caused no end of trouble for users, maintainers, and upstreams) -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bug lies in (presently) unused code path
user [EMAIL PROTECTED] usertag 469013 -goal-python2.5 retitle 469013 Python API memory handling bug in unused code path found 469013 3.0-unstable+hg11561-1 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in xen-unstable-3.0-unstable+hg11561/tools/pygrub/src/fsys/ext2/ext2module.c) is not actually compiled and the results shipped[1]. As such, while a fix still seems to be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. Just be that it does not get activated its present buggy form. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. 1. It should compile a module _ext2, I did not find any indication that it is contained in the binary packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bug lies in (presently) unused code path
user [EMAIL PROTECTED] usertag 469001 -goal-python2.5 severity 469001 normal retitle 469001 buggy Python API memory handling in unused source code found 469001 0.6.0-8 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in python-scipy-0.6.0/scipy/sandbox/netcdf/_netcdf.c) is not actually compiled and the results shipped. As such, while a fix still seems to be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. Just be sure not to include the buggy C module before fixing it. Noticing that a pure python implementation (python-scipy-0.6.0/scipy/io/netcdf.py) is used, it might be nice to see whether the netcdfg-dev build-dependency should be revisited. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bug lies in (presently) unused code path
user [EMAIL PROTECTED] usertag 468977 -goal-python2.5 retitle 468977 Python API memory handling bug in unused code path found 468977 0.90.1-3.1 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in matplotlib-0.90.1/src/_subprocess.c) is not actually compiled and the results shipped[1]. As such, while a fix still seems to be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. Just be that it does not get activated its present buggy form. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. 1. from matplotlib-0.90.1/src/_subprocess.c: * Currently, this extension module is only required when using the * subprocess module on Windows, but in the future, stubs for other * platforms might be added here as well. and it is indeed not compliled on Debian. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bug lies in (presently) unused code path
user [EMAIL PROTECTED] usertag 468970 -goal-python2.5 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in egenix-mx-base-3.0.0/mx/Tools/mxTools/xmap.c) is not actually compiled and the results shipped. As such, while a fix might still be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bug lies in (presently) unused code path
user [EMAIL PROTECTED] usertag 468965 -goal-python2.5 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in ecasound2.2-2.4.6.1/pyecasound/pyecasound.c) is not actually compiled and the results shipped. As such, while a fix still seems to be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. Just be sure not to switch from the pure python implementation to the C implementation before fixing it / using a fixed upstream version. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
code with this bug does not seem to be compiled / shipped
user [EMAIL PROTECTED] usertag 469006 -goal-python2.5 usertag 468968 -goal-python2.5 severity 469006 normal severity 468968 normal thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in Tools/WAD/Python/types.c) is not actually compiled and the results shipped. As such, while a fix might still be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. The same seems to be true of cableswig. Note that swig1.3 will need a sourceful upload correcting the python2.4 references in the build-dependencies and rules when python2.5 becomes the default. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to get python-numpy to testing
Steve Langasek wrote: The package is failing to build on arm with a swig error: http://buildd.debian.org/fetch.cgi?pkg=python-scipyarch=armver=0.6.0-5stamp=1198958132file=logas=raw I don't know why this is happening only on arm, but it needs resolved before these packages will be updated in testing. I seem to be able to reproduce this build failure in a clean cowbuilder chroot. It goes away if I see to -I/usr/include being passed to the failing swig call, to test, I just did 'export SWIG_FEATURES=-I/usr/include' before building the package, that looks like it is working. On arm, apparently in contrast to (at least one of) the other atlas3-base-dev is not installed, but I'm not sure whether that is of importance. Both build logs I looked at noted libsuitesparse-dev, the package containing the file swig is missing, being installed as required by the build-depends, both in the same version. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Python transition for ldaptor
Hi Jakko, Pierre, Python experts, and Release Team, looking at ldaptor, I think that it might not have been updated to the python-policy. So I'm wondering whether it's desirable to NMU ldaptor again with something along the lines of Pierre's patch. Jakko is the last NMUer, so I'm CCing him as well. Quite possibly, #408492 would be worth fixing as well. If the bug report's description is correct, it sounds awfully close to a renders package useless bug. Any comments? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#406557: RFP: python-wavelets -- python extension implementing of wavelet transformations
Yaroslav Halchenko wrote: It seems that one.pl DNS servers are bad now... can't resolve even pox.one.pl now. Alternative location? ip? As Piotr pointed out, it's already uploaded. If you need the package itself, it's on p.d.o.[1] Kind regards T. 1. http://people.debian.org/~tviehmann/debian/unstable/ -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Joining PMPT
Hi, Raphael Hertzog wrote: We really need some more DD who could help sponsoring, for example Ian Ward seems to have trouble finding sponsors for his urwid package. It seems somebody else picked up urwid. I'm not sure I'll be able to this on a regular basis, but sponsoring an occasional update should be possible. I'm afraid I'll only take new packages if I have a particular interest. Is there a place where people look for that? If it's the alioth list: Do you happen to know whether it's available via gmane? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406557: RFP: python-wavelets -- python extension implementing of wavelet transformations
Package: wnpp Severity: wishlist I'd be very thankful if the following could be packaged. I'd be able to sponsor non-DDs if the packages are good. * Package name: python-wavelets Version : 0.1.6 Upstream Author : Filip Wasilewski [EMAIL PROTECTED] * URL : http://cheeseshop.python.org/pypi/PyWavelets/ http://www.pybytes.com/pywavelets/ * License : MIT Description : python extension implementing of wavelet transformations PyWavelets implements the discrete wavelet transform (DWT) popular in numerical harmonic analysis for numerous families of wavelets, including Haar, Daubechies, Symlet, Coiflet, biorthogonal wavelets in one and two dimensions. . PyWavelets is implemented as a python extension for speed and uses NumPy numeric arrays. The supported python versions seem to be thoe = 2.4, the python-numpy dependency is stated as = 0.9.8. Kind regards and TIA T. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-023stab033.6-enterprise Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
detecting the right /usr/lib/python2.x in an upstream-compatible way
Hi, Matthias Klose filed a bug and patch against pyx because it had a hardcoded /usr/lib/python2.3. Thanks! The bugfix is to detect the python version and then use /usr/lib/python$(PYTHON_VERSION). While this is obviously correct for Debian, I'm wondering whether it would be better to use something like $(python -c import os.path, site ; print os.path.dirname(site.__file__)) in order be able to share with upstream who might want to cater for local python installations (pyx upstream has import site; print site.here in SVN but that doesn't work in python = 2.4). Any comments? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pysupport and site-packages
Josselin Mouette wrote: I don't think /usr/lib/python is handled by python-support. If it is, that's an unexpected feature :) No it doesn't, sorry for the noise... If you want to just ship some .py files manually, the simplest way is probably to install them to /usr/share/python-support/$package instead of /usr/lib/python2.X/site-packages. Well, /usr/lib/python/site-packages seems to be both version and helper-neutral, so I thought that this would be nice to have just in case someone wants to adapt things to a non-debian environment or somesuch. Also, it might be the obvious location for upstream to install stuff into. As such, maybe it's worth supporting. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pysupport and site-packages
Hi, in the pysupport documents (python-policy, Manoj's writing, package README), the site-packages directories I've seen mentioned all seem to be /usr/lib/pythonX.Y. Packages installing .pys there usually have to work to find out X and Y and AFAIUI /usr/lib/python is dealt with by pysupport just as well. I there a reason not to include the unversioned path in the docs? Thanks for making python packaging easier! Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python .egg support in Debian
Bob Tanner wrote: Is there an agreement amongst the interested debian-python developers/packagers that Debian must support .egg's? Well, let's agree that this is desirable, perhaps strongly, depending on how widespread the use of .eggs is, to support applications using it. Answering the -IF- will let us move forward to the HOW. Likely the IF is connected to the HOW: The number of Debian python people objecting to zipped .egg files seems to be far larger than those not willing to support some form of unpacked eggs. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python policy proposed changes
Antal A. Buss wrote: So, it's possible to install new modules to default, legacy and new version of Python, maintained only one package, using package dependency to know which Python version check. Specific modules are installed without check installed version This is a good idea, if - modules are compatible with the involved python versions (could be specified by maintainer) - modules are pure python (i.e. compilation of C/C++.. modules at run-time is not an option) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hunting useless binary packages
Hi Josselin. Josselin Mouette wrote: 3. In most cases, they are useless. The python policy allows such packages for cases where a specific python version is required by a reverse dependencies. However, it should have been the exception and not the rule. That's the option [that] is recommended for most modules packages per python policy. How about changing that first? Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libcurl3 upgrade breaks pycurl
Fred Blaise wrote: Ran upgrade on the 14th, and it seems an upgrade to libcurl3 broke pycurl.. :/ Many of our scripts run on that. This seems to have been a bug in the libcurl3 package [1] and fixed in libcurl3 7.13.1-2. Kind regards T. 1. http://bugs.debian.org/299525 -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Splitting ZODB from Zope package
Matthias Klose wrote: If we change Python policy according to this I would fully agree here. Anybody to write the PEP and define the import rules? I'm not sure whether I'm qualified, but I'd sure like to help. - which order do have arch dependent and arch-independent directories? concatenated, intertwined? I think for default directories, arch dependent should take precedence. IMHO it's far more likely that a arch-specific module overcomes an arch-independent module's shortcomings than the other way round. Also, it might be nice to have the location where the old-fashioned user looks first take precedence for a friendlier transition. - how should packages install their files, when providing shared modules and .py files? how to do this in a compatible way? In what way would it hurt to split them? Cheers T. pgphTlJgNeccN.pgp Description: PGP signature
Re: vpython installation question
Hi Luda, Liudmila Yafremava wrote: Could anyone please kindly help me with VPython installation on Debian? I followed the instructions on VPython website and got all necessary libraries, still no luck. I pulled VPython installation script apart and tried executing each command separately. When I try /usr/bin/python2.2 setup.py install it complains that it cannot find module distutils. Why could that be? What should I do to overcome that? You need to install python2.2-dev. If you with to use the installing much is much help-approach, you might want to use tasksel to install the Python task. Cheers Thomas P.S.: Even if that's OT: What language/region is you name originally from? (Maybe you answer that in a private mail unless it's python specific.) pgpZXy4TGFyIx.pgp Description: PGP signature
Can someone NMU bug 151464 in zope-zpatterns?
Hi. (I'm not on debian-python, so I'd appreciate CC's.) I thought this might be the place where I could get help. I've submitted http://bugs.debian.org/151464 a while ago. I wonder whether some developer who knows python and/or zope could NMU. Another user just mailed me about the bugreport, because he had the same problem and so I thought maybe someone could actually do something about it. Regards Thomas
