Mailman 3 April 2005 - pytest-dev

[py-dev] capturing / doctests / py lib release
by hpk＠trillke.net April 30, 2005

April 30, 2005

Hi py-dev, i am wondering if anybody would mind (or endorse) not catching stderr by default but only stdout? There would be a switch ('-e' or something) that would enable capturing of stderr as it is now. Or should there just be a switch to turn off stdout/stderr capturing separately but keep the defaults to catch both? On a side note, i am probably not going to release the py lib before end of May because of the missing fleshing out of win32 support. Nobody, including me, has the time and will so far to fix things about it. In case you haven't noticed, i am looking for a co-developer familiar with the win32 platform(s). You get full commit rights and strong influence on how things are done on win32 and the lib in general in return, apart from fame and glory. Generalizing this: if any of you wants to help drive the py lib please feel free to take things over. Btw, i am very happy that Jan Balster took over the development of a tkinter frontend ("py.test --tkinter") which looks very promising already. If you have suggestions or improvements for this frontend please post to this list, Jan would be happy to get feedback. I do, however, intend to work on doctest integration real soon now. Mind you, this is a free software programmer saying this but then one, who also is contractually bound by the European Union to get certain py.test related features working for PyPy so bets are not all off. I consider the "how to collect doctests" issues still the primary blocker design question. cheers, holger

2 1

[py-dev] my first post to the list
by Michele Simionato April 29, 2005

April 29, 2005

Well, after seeing Armin presentation at the ACCU conference I have decided to keep a close eye on what it is going on at codespeak.net ;) He gave a couple of pretty convincing talks. Personally, I am more interested in the py library, since it works with current Python now, whereas the PyPy project is a more long term one. So today I spent some time playing with greenlets. As an exercise, I was trying to implement generators using greenlets (I know there is an example on site, but I wanted to do it on my own) and I am a bit confused. I wanted to write the equivalent of this: def _gen123(): yield 1 yield 2 yield 3 for i in _gen123(): print i I thought this should work: from py.magic import greenlet @greenlet def main(): while True: try: print "switching ..." print gen123.switch() except StopIteration: break @greenlet def gen123(): print "gen123 start ..." greenlet.getcurrent().parent.switch(1) greenlet.getcurrent().parent.switch(2) greenlet.getcurrent().parent.switch(3) raise StopIteration main.switch() print "Done" However, it does not work as I would expect, the controls goes immediately back to the toplevel. Any hint about what I am doing wrong? Michele Simionato

2 4

[py-dev] doctests again
by Ian Bicking April 26, 2005

April 26, 2005

I'm just checking in... is there any preferred way to do doctests with py.test now? Holger mentioned something, but he hadn't integrated reporting yet or something. But fancy reporting or not, I'd like to run those doctests too... I can dig up that old recipe I posted a while ago, but maybe there's a better way to do it now. Does doctest.DocTestSuite() work okay? I haven't looked at the unittest compatibility since it was mentioned. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 1

[py-dev] towards a 0.8.0 release!
by hpk＠trillke.net April 25, 2005

April 25, 2005

Hi folks, a few notes and questions regarding the to-be-released py lib, named '0.8.0': - there now is a setup.py in the 'svn/py/dist' directory which should work at least on unix-ish systems. Note that the "setup install" command will basically install the whole tree of the py lib including all svn-control files. This means that you can go to '../python-2.X/site-packages/py' and issue 'svn up'. It also means that when you fix things, you can run 'svn diff' there to create a patch. Or, if you have a codespeak account you can branch easily to test some idea out etc.pp. - the main missing piece is testing things much more on windows (speaking of which: has anyone recently used py.test on win32 and could try out: python py/bin/py.test py and possibly python setup.py install that would be great. I am sure that at least the installation of 'py.test' as a script will not work and i have not clue how to do it myself. Brian Dorsey suggested in private conversation to write an Immo binary Installer. - when 0.8.0 comes out, i basically want the directory release layout to look like this: http://codespeak.net/py/current/doc/releasescheme.html this means in particular: * svn/py/trunk will then hold head development * svn/py/branch/0.8 will be the ongoing release branch * svn/py/tag/0.8.x will be a tagged release * svn/py/dist will always hold the newest release and will not be writeable/commitable most of the time (i'll also prevent commits to 'tag/', i guess) - until 1.0 there will be _no_ particular release guarantees but i will be trying to follow and refine: http://codespeak.net/py/current/doc/why_py.html#upcoming-release-policy-api… - i'd like to have 1.0 latest at EuroPython end of June feedback & help welcome, holger

8 11

[py-dev] print statements during collect
by Ian Bicking April 25, 2005

April 25, 2005

When I have print statements during the collect phase, they seem to be lost forever (unless I turn off stdout capture). I think it would be best if, in the case of any error, all the printout during collection was also shown (probably distinguished from prints during test runs). -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

Re: [py-dev] towards a 0.8.0 release!
by holger krekel April 24, 2005

April 24, 2005

Hi Paul, trying to strip it down a bit ... On Sun, Apr 24, 2005 at 21:53 +0100, Paul Moore wrote: > On 4/24/05, holger krekel <hpk(a)trillke.net> wrote: > > And does that mean that the installation and i invoking > > 'py.test' worked? > > Of course not :-) as the file was installed as "py.test" and not as > some circumlocution involving a .bat file, or as py.test.py, to be run > with that name. OK, i had the faint and irrational hope that things passed as 'scripts' to setup() would maybe install them appropriately on windows (which shouldn't be impossible to achieve, should it?). > On the other hand, copying the "py.test" script to somewhere else > (somewhere on my PATH) and renaming it as, for example, py.test.py, > fails with ... Yes, I found it. It's the _findpy.py module > again. I stand by my comments from a while back, that the > existence of this module is a symptom of a problem. To find > the "py" module, you should be doing "import py"!!! It does fall back to 'import py' these days! Btw, I haven't of heart of problems regarindg _findpy (once you have it properly installed) and it does definitely have advantages at least being a developer, working with different versions. > ... > > [Meta-comment here - I still get the feeling that there's "too much > magic" going on. Please also understand that i don't currently have access to a win32 platform. > py.test script, and move it anywhere I want, and rename it as I like, > and have it still work. That doesn't happen, and that counts as > "magic" to me.] Maybe the _findpy logic should be folded into py.test itself so that it becomes self contained and can easily work with a site-packages installed py lib. > > > I strongly disagree with the idea of including the > > > Subversion control stuff in the installed copy, in any case. In my > > > view, you shouldn't be doing "svn up" in your site-packages tree, > > > > .. it's also 'svn info' and 'svn diff' that is useful IMO ... > > Again, not from the installed copy. If it matters, make the version > include the Subversion revision number, by all means, but that's all. > Unix practice may be different, but on Windows, I'd consider it very > bad practice to be working in a directory under "Python24" - ever. ok, i guess i will be dropping it. In fact i put new "0.8.0-alpha1" installers for unix & windows at http://codespeak.net/download/py They don't contain the '.svn' directories anymore but i am not sure that the windows installer really contains all the files ... Generally, i have to admit that i am just frustrated at the lack of versioning/dependency handling by Python's distribution mechanisms. It has bitten me more than once and i wanted to try out the 'have it svn ready just in case' to get some anchor in it. > ... > ("C:\Apps\Python24\Removepy.exe" -u "C:\Apps\Python24\py-wininst.log") > - the latter is built by the bdist_wininst installer and contains a > listing of all the files and directories installed. Doing something > like "svn up" from within the site-packages directory would totally > break this uninstaller. Side note: i like the notion of having installed applications completely contained in one directory. That also makes uninstallation trivial. > Perhaps you could explain why you *don't* have an issue with using svn > on installed files? There simply isn't any problem to note from my side. (i am running it on two production machines ...). > > Sorry, C-extensions are not built at all currently. > > Fair enough. But when you do get it building C extensions, you'll get > installer support on Windows "for free" - if setup.py build works, > then setup.py bdist_wininst does too. It's pretty slick. I hope it's feasible to get a win32 build environment for 2.2, and 2.3 and 2.4 on one machine going (and without spending money for licenses ...). cheers, holger

1 0

[py-dev] greenlets on amd64 (x86_64)
by Armin Rigo April 24, 2005

April 24, 2005

Hi, Some time ago, Hye-Shik Chang posted a patch for Stackless to support switching on amd64, on the stackless mailing list. I have put his switch_amd64_unix.h into py's greenlets and gave it a bit of (successful) testing. Enjoy! A bientot, Armin

1 0

[py-dev] Import errors
by Ian Bicking April 23, 2005

April 23, 2005

Well, I'm doing a big renaming, and the errors from bad imports are a bit confusing. It seems whenever there's an import error, the module with the error still gets loaded, but is empty. This is a bit confusing to debug. Well, this isn't true in the test_* module, but in the modules they import. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

3 3

[py-dev] distutils question
by hpk＠trillke.net April 23, 2005

April 23, 2005

Hi folks, i have written simple distutils scripts before but i am now looking into writing a setup.py (and helpers) for the py lib. Thing is i would like to just say: please install the full package including any and all of its files (yes that means including '.svn' files, which you may disagree with but let's not argue about that right now). Is there an easy way to do it or do i have to hack things? I somehow can't believe that i have to more or less trick distutils into just installing a full directory tree, (compiling any pyc file in it as a bonus :-). Oh, and please only suggest things that work on python 2.2.x onwards if possible. any help and suggestions welcome, holger

3 3

[py-dev] branch is being merged back
by hpk＠trillke.net April 18, 2005

April 18, 2005

Hi all, we are currently merging back the py-collect branch [1]. Although this is a huge diff we don't expect big problems unless you are using "conftest.py" customizations. There are a couple of new command line options, most notably Jan Balster's "--tkinter" frontend. It's at an early experimental stage but already starts to be usable. Note that the command line options changed slightly, because there is a new rule: py.test will consume all lowercase single-letter options like "-h", "-v", "-x" and so on while applications should add only consume capital cased letters. One major change that took place in the branch is that we are refraining from import magic for importing test modules. This deprives us of the ability to run tests directly from a remote repository, but allows to get rid of some nasty interactions with e.g. nevow's import hacks. have fun and report any problems, holger [1] Jan, if you have a locally modified pycollect branch you will have to switch to the dist directory because the branch/py-collect is no more and you can't commit to it ...

3 2