Re: Python 2.7 status on Ubuntu Maverick
* Jakub Wilk , 2010-07-28, 18:35: looking at sip4-qt3 build log, even the PPA version provides only modules for 2.6, which looks like a bug in sip4-qt3. Actually, it's python-defaults in toolchain2.7 PPA, which does not support python2.7. Yay. -- Jakub Wilk signature.asc Description: Digital signature
Re: Python Testing -- should be there uniformity?
On Jul 27, 2010, at 09:48 PM, Yaroslav Halchenko wrote: >well, both "setup.py test" and "module.test()" sound like reasonable >interfaces to adhere to. Yes, especially if 'python -m module.test' were an available command line interface. The former could be promoted for in-development testing and the latter could be promoted for deployed package testing (i.e. where you wouldn't have a setup.py). Probably the best place to continue discussing this is in the TIP mailing list, except perhaps as it applies specifically to Debian. -Barry signature.asc Description: PGP signature
Testing Python modules (was Re: Numpy API change?)
On Jul 27, 2010, at 05:56 PM, Yaroslav Halchenko wrote: >On Thu, 22 Jul 2010, Barry Warsaw wrote: >> In my copious spare time , I'm working on code, documentation, >> and infrastructure to make this the preferred way of testing Python >> modules and applications. You don't *have* to conform, but we'll >> put out big carrots for you if you do. > >do you have somewhere any documentation available on this >infrastructure so we could point upstreams to follow? I don't at the moment, but I really need to put such a wiki page together. It's just gotten pushed down on the stack. :( >are you recommending nose as the testing framework? what internal >organization of the modules to support it do you recommend... i.e. in a few >modules I saw (and we somewhat adopted in our projects) having I'm currently in favor of unittest2, but nose has some nice features. When unit2's plugin architecture is done, I think that'll probably be the way I want to go. >project/data -- minimalistic data sets (if) necessary for >testing/examples project/testing -- tools >project/tests-- actual unittests which rely on project.testing It's an open question, and I know there are a million different ways people structure their tests! I generally have project/testing for support code, project/testing/data for test data sets, project/tests for unittests and project/docs for doctests. >alternative strategy is to take advantage of nose discovery allows >to keep unittests closer to respective code, so /tests is not needed >any longer... True. I like separating my tests into submodules, and I don't personally like in-docstring doctests, so I'm biased toward those decisions. -Barry signature.asc Description: PGP signature
Python testing (was Re: Numpy API change?)
On Jul 28, 2010, at 12:23 AM, Sandro Tosi wrote: >anyhow, since I'm at it: please don't force ANY testing tool; I kinda >like unittest2, and it's available in python2.7 stdlib, and it's also >backported to 2.4-2.6 (and even packaged for debian), and I don't want >to be forced to use nose for my upstream development. Hi Sandro, This isn't about forcing anything on anyone! This is Python we're talking about so despite the Zen, there will always bee a million ways to do things. :) Really this is about helping build a common meme for simple and common tasks, and giving beginners a clear bright path to start their journey on. There will always be fun things to explore out in the wilderness, but sometimes you just want the simple path, and beginners can be overwhelmed by the choices. Experienced developers will always be able to do whatever they want! -Barry signature.asc Description: PGP signature
Re: Python 2.7 status on Ubuntu Maverick
On Jul 29, 2010, at 03:35 PM, Jakub Wilk wrote: >* Jakub Wilk , 2010-07-28, 18:35: >>looking at sip4-qt3 build log, even the PPA version provides only >>>modules for 2.6, which looks like a bug in sip4-qt3. > >Actually, it's python-defaults in toolchain2.7 PPA, which does not >support python2.7. Yay. Looks like a resync pulled a newer version that blew away my py27 enabled package. This is depressing :( -Barry signature.asc Description: PGP signature
Re: Bug#590525: python-gtk2: pygtk was not compiled with Numeric Python support
On Tue, Jul 27, 2010 at 11:41:19AM +0200, Emilio Pozuelo Monfort wrote: > On 27/07/10 08:54, Sandro Tosi wrote: > > On Tue, Jul 27, 2010 at 08:48, Josselin Mouette wrote: > >> Le mardi 27 juillet 2010 à 10:33 +0900, Shyouzou Sugitani a écrit : > >>> After upgrading from 2.17.0-2 to 2.17.0-3 I got an error > >>> "pygtk was not compiled with Numeric Python support". > >>> > >>> $ python > >> import gtk > >> pixbuf = gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, True, 8, 100, 100) > >> pixbuf.get_pixels_array() > >>> Traceback (most recent call last): > >>> File "", line 1, in > >>> RuntimeError: pygtk was not compiled with Numeric Python support > >> > >> I guess this is caused by the NumPy ABI disaster. > > > > Can you please try to rebuild it with the current numpy in unstable? > > that should be fixed. > > Indeed, the problem was the include files you fixed in -3: > > > checking for numpy/arrayobject.h... no > [...] > Numpy support: no > > Rebuilding with -3 installed fixes it. > > > > Dear wanna-build maintainers: > > Can you binNMU pygtk_2.17.0-3 on sparc s390 mipsel mips kfreebsd-i386 > kfreebsd-amd64 ia64 hurd-i386 hppa armel i386 > > Also dep-wait it for python-numpy 1:1.4.1-3, which is the fixed package we > need. This already seems to have been done. Kurt -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100730052128.ga9...@roeckx.be
