From p.f.moore at gmail.com  Tue Feb  1 23:54:18 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 1 Feb 2005 22:54:18 +0000
Subject: [py-dev] Setup.py for the py library
Message-ID: <79990c6b050201145437bd0a48@mail.gmail.com>

What's involved in creating a setup.py for the py library? I know the
install instructions say just to put the dist-py directory on your
PYTHONPATH, but I *really* prefer building bdist_wininst installers
for everything I use (I'm on Windows) as it makes it so much easier to
remember what's installed.

I'm guessing that just packaging up the "py" directory/package is most
of it. But what about the greenlets stuff? That has its own setup.py,
and I don't know how to include that (or indeed if greenlets are
needed at all at this point...)

Thanks,
Paul.


From hpk at trillke.net  Thu Feb  3 17:34:32 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 3 Feb 2005 17:34:32 +0100
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <79990c6b050201145437bd0a48@mail.gmail.com>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
Message-ID: <20050203163432.GQ9235@solar.trillke.net>

Hi Paul, 

On Tue, Feb 01, 2005 at 22:54 +0000, Paul Moore wrote:
> What's involved in creating a setup.py for the py library? I know the
> install instructions say just to put the dist-py directory on your
> PYTHONPATH, but I *really* prefer building bdist_wininst installers
> for everything I use (I'm on Windows) as it makes it so much easier to
> remember what's installed.

I haven't aimed at doing a setup.py for the py lib yet. 
i guess it shouldn't be hard. 

> I'm guessing that just packaging up the "py" directory/package is most
> of it. But what about the greenlets stuff? That has its own setup.py,
> and I don't know how to include that (or indeed if greenlets are
> needed at all at this point...)

greenlets are not needed by the other code so if you just want 
to try a setup.py out you can leave it out for now (or paste 
the contents of greenlets' setup.py into the new main one). 

One issue is to have at least "py/bin/py.test" become a cmdline
utility.  I don't know how this is done on windows. If you 
get to something workable then we can integrate into the trunk. 

cheers, 

    holger


From p.f.moore at gmail.com  Thu Feb  3 17:36:37 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 3 Feb 2005 16:36:37 +0000
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <20050203163432.GQ9235@solar.trillke.net>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
	<20050203163432.GQ9235@solar.trillke.net>
Message-ID: <79990c6b0502030836f4e242e@mail.gmail.com>

On Thu, 3 Feb 2005 17:34:32 +0100, holger krekel <hpk at trillke.net> wrote:
> I haven't aimed at doing a setup.py for the py lib yet.
> i guess it shouldn't be hard.
[...]
> greenlets are not needed by the other code so if you just want
> to try a setup.py out you can leave it out for now (or paste
> the contents of greenlets' setup.py into the new main one).

OK, I'll have a go at that.

> One issue is to have at least "py/bin/py.test" become a cmdline
> utility.  I don't know how this is done on windows. If you
> get to something workable then we can integrate into the trunk.

Shouldn't be too hard. I'll see what I can come up with, and post the results.

Paul.


From p.f.moore at gmail.com  Thu Feb  3 21:02:53 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 3 Feb 2005 20:02:53 +0000
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <79990c6b0502030836f4e242e@mail.gmail.com>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
	<20050203163432.GQ9235@solar.trillke.net>
	<79990c6b0502030836f4e242e@mail.gmail.com>
Message-ID: <79990c6b050203120243bc13bc@mail.gmail.com>

On Thu, 3 Feb 2005 16:36:37 +0000, Paul Moore <p.f.moore at gmail.com> wrote:
> On Thu, 3 Feb 2005 17:34:32 +0100, holger krekel <hpk at trillke.net> wrote:
> > I haven't aimed at doing a setup.py for the py lib yet.
> > i guess it shouldn't be hard.
> [...]
> > greenlets are not needed by the other code so if you just want
> > to try a setup.py out you can leave it out for now (or paste
> > the contents of greenlets' setup.py into the new main one).
> 
> OK, I'll have a go at that.

Hmm, 36 subpackages - is that right? Should the 'testing' subpackages
be included - they look like tests of the py package itself rather
than parts of the package. That's 19 subpackages worth.

The greenlets stuff built OK. By the way, is there any documentation
on greenlets anywhere (short of the source code...)

> > One issue is to have at least "py/bin/py.test" become a cmdline
> > utility.  I don't know how this is done on windows. If you
> > get to something workable then we can integrate into the trunk.

Working on that next...

Paul.


From hpk at trillke.net  Thu Feb  3 22:33:59 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 3 Feb 2005 22:33:59 +0100
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <79990c6b050203120243bc13bc@mail.gmail.com>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
	<20050203163432.GQ9235@solar.trillke.net>
	<79990c6b0502030836f4e242e@mail.gmail.com>
	<79990c6b050203120243bc13bc@mail.gmail.com>
Message-ID: <20050203213359.GX9235@solar.trillke.net>

On Thu, Feb 03, 2005 at 20:02 +0000, Paul Moore wrote:
> On Thu, 3 Feb 2005 16:36:37 +0000, Paul Moore <p.f.moore at gmail.com> wrote:
> > On Thu, 3 Feb 2005 17:34:32 +0100, holger krekel <hpk at trillke.net> wrote:
> > > I haven't aimed at doing a setup.py for the py lib yet.
> > > i guess it shouldn't be hard.
> > [...]
> > > greenlets are not needed by the other code so if you just want
> > > to try a setup.py out you can leave it out for now (or paste
> > > the contents of greenlets' setup.py into the new main one).
> > 
> > OK, I'll have a go at that.
> 
> Hmm, 36 subpackages - is that right? Should the 'testing' subpackages
> be included - they look like tests of the py package itself rather
> than parts of the package. That's 19 subpackages worth.

Hum, i just counted the number of non-dot directories via len of 

    list(py.path.local().visit(py.path.checker(dir=1, dotfile=0), 
                               py.path.checker(dotfile=0)))

and unsurprisingly it is 42 :-) 

IOW, what do you mean with subpackages? 

> The greenlets stuff built OK. By the way, is there any documentation
> on greenlets anywhere (short of the source code...)

ASFAIK not yet.  I guess i may be able to donate some time 
to write some documentation about greenlets. Christian 
or Armin would be better qualified though. 

cheers, 

    holger


From p.f.moore at gmail.com  Fri Feb  4 00:30:46 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 3 Feb 2005 23:30:46 +0000
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <20050203213359.GX9235@solar.trillke.net>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
	<20050203163432.GQ9235@solar.trillke.net>
	<79990c6b0502030836f4e242e@mail.gmail.com>
	<79990c6b050203120243bc13bc@mail.gmail.com>
	<20050203213359.GX9235@solar.trillke.net>
Message-ID: <79990c6b0502031530451b69c6@mail.gmail.com>

On Thu, 3 Feb 2005 22:33:59 +0100, holger krekel <hpk at trillke.net> wrote:
> Hum, i just counted the number of non-dot directories via len of
> 
>     list(py.path.local().visit(py.path.checker(dir=1, dotfile=0),
>                                py.path.checker(dotfile=0)))
> 
> and unsurprisingly it is 42 :-)
> 
> IOW, what do you mean with subpackages?

I only counted directories with an __init__.py in them - ie, ones
Python will recognise as packages.

It's not too important, the setup.py is easy to modify regardless.

> > The greenlets stuff built OK. By the way, is there any documentation
> > on greenlets anywhere (short of the source code...)
> 
> ASFAIK not yet.  I guess i may be able to donate some time
> to write some documentation about greenlets. Christian
> or Armin would be better qualified though.

No big deal - I'm only curious. Actually, the test_greenlet code gives
me a bit of a feel for how greenlets work.

Oh, I've been looking in the py\bin directory. If I understand
_findpy.py, this searches for the "py" library on the assumption that
it's *not* in sys.path. So, if the py library is installed on
sys.path, am I right in thinking that _findpy isn't needed?

Paul.


From hpk at trillke.net  Fri Feb  4 00:53:48 2005
From: hpk at trillke.net (holger krekel)
Date: Fri, 4 Feb 2005 00:53:48 +0100
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <79990c6b0502031530451b69c6@mail.gmail.com>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
	<20050203163432.GQ9235@solar.trillke.net>
	<79990c6b0502030836f4e242e@mail.gmail.com>
	<79990c6b050203120243bc13bc@mail.gmail.com>
	<20050203213359.GX9235@solar.trillke.net>
	<79990c6b0502031530451b69c6@mail.gmail.com>
Message-ID: <20050203235348.GA9235@solar.trillke.net>

On Thu, Feb 03, 2005 at 23:30 +0000, Paul Moore wrote:
> Oh, I've been looking in the py\bin directory. If I understand
> _findpy.py, this searches for the "py" library on the assumption that
> it's *not* in sys.path. So, if the py library is installed on
> sys.path, am I right in thinking that _findpy isn't needed?

_findpy first searches directory-upwards to find an importable
py lib.  This allows to have multiple versions/checkouts for
multiple projects (some people really have that :-) and have
the "local" one used.  Basically this avoids the disruptiveness of
managing library versions at global level.  It's admittedly a
bit hacky but serves its purpose well so far.  However, with
setup.py's we may want to eventually fall back to just try to
import py if we can't find it otherwise. 

    holger


From arigo at tunes.org  Sat Feb  5 00:26:50 2005
From: arigo at tunes.org (Armin Rigo)
Date: Fri, 4 Feb 2005 23:26:50 +0000
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <79990c6b050203120243bc13bc@mail.gmail.com>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
	<20050203163432.GQ9235@solar.trillke.net>
	<79990c6b0502030836f4e242e@mail.gmail.com>
	<79990c6b050203120243bc13bc@mail.gmail.com>
Message-ID: <20050204232650.GA17398@vicky.ecs.soton.ac.uk>

Hi Paul,

On Thu, Feb 03, 2005 at 08:02:53PM +0000, Paul Moore wrote:
> The greenlets stuff built OK. By the way, is there any documentation
> on greenlets anywhere (short of the source code...)

I tried to write some docs in py/documentation/greenlet.txt.  I don't know if
it makes sense or if it is just too obfuscated.  I guess a few extra examples
would be useful.


Armin


From p.f.moore at gmail.com  Sat Feb  5 11:55:09 2005
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 5 Feb 2005 10:55:09 +0000
Subject: [py-dev] Setup.py for the py library
In-Reply-To: <20050204232650.GA17398@vicky.ecs.soton.ac.uk>
References: <79990c6b050201145437bd0a48@mail.gmail.com>
	<20050203163432.GQ9235@solar.trillke.net>
	<79990c6b0502030836f4e242e@mail.gmail.com>
	<79990c6b050203120243bc13bc@mail.gmail.com>
	<20050204232650.GA17398@vicky.ecs.soton.ac.uk>
Message-ID: <79990c6b05020502554bac00a@mail.gmail.com>

On Fri, 4 Feb 2005 23:26:50 +0000, Armin Rigo <arigo at tunes.org> wrote:
> I tried to write some docs in py/documentation/greenlet.txt.  I don't know if
> it makes sense or if it is just too obfuscated.  I guess a few extra examples
> would be useful.

It looks really good. At least, I followed it fine :-)

>From my experience, greenlets are basically coroutines - is that
right? Certainly, by thinking in terms of what I know about coroutines
I found greenlets easy to understand - at least as much as I found
coroutines easy to understand :-)

Thanks!
Paul.


From ianb at colorstudy.com  Wed Feb  9 09:27:07 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 09 Feb 2005 02:27:07 -0600
Subject: [py-dev] assertions and magic
Message-ID: <4209C95B.7020703@colorstudy.com>

A little bug: I notice that with magic on py.test doesn't show the 
message for assertion errors.  There's often useful information in 
those, so it's a shame to throw away that text if it is available, even 
if you can augment it as well.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org


From phd at phd.pp.ru  Sat Feb 12 20:36:32 2005
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Sat, 12 Feb 2005 22:36:32 +0300
Subject: [py-dev] py.test and python 2.2
Message-ID: <20050212193632.GB20920@phd.pp.ru>

Hello! I'd like to add a minor patch - to use py.test with python 2.2
you need to add "from __future__ import generators" to the beginning of
the py/execnet/channel.py.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.


From hpk at trillke.net  Sat Feb 12 23:33:13 2005
From: hpk at trillke.net (holger krekel)
Date: Sat, 12 Feb 2005 23:33:13 +0100
Subject: [py-dev] py.test and python 2.2
In-Reply-To: <20050212193632.GB20920@phd.pp.ru>
References: <20050212193632.GB20920@phd.pp.ru>
Message-ID: <20050212223313.GU28668@solar.trillke.net>

Hi Oleg, 

On Sat, Feb 12, 2005 at 22:36 +0300, Oleg Broytmann wrote:
> Hello! I'd like to add a minor patch - to use py.test with python 2.2
> you need to add "from __future__ import generators" to the beginning of
> the py/execnet/channel.py.

Thanks for hinting at this.  Seo Sanghyeon actually also "fixed" 
this at some point and i immediately reverted the patch. 
The thing is that running 'py.test' on the py lib itself 
with this patch generates failing tests :-) 

The underlying problem is (or rather was) that the contents of
channel.py are used in two ways: once for just importing it
and once for making it a part of a larger source code, used
for "gateway" initialization.  See 

    http://codespeak.net/py/current/doc/execnet.html

for some details about gateways.  When you invoke something like 

    py.test --exec=python2.2 

it is really handled by this mechanism which basically 
allows to run tests on different machines as well. 
You did use py.test like this, didn't you? 

The good news is that I now got rid of the shallow 'yield'
usage in favour of an old-style __iter__ implementation.  So
the problem should be gone since rev 9174. 

have fun, 

    holger


From phd at phd.pp.ru  Sat Feb 12 23:35:26 2005
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Sun, 13 Feb 2005 01:35:26 +0300
Subject: [py-dev] py.test and python 2.2
In-Reply-To: <20050212223313.GU28668@solar.trillke.net>
References: <20050212193632.GB20920@phd.pp.ru>
	<20050212223313.GU28668@solar.trillke.net>
Message-ID: <20050212223526.GC24093@phd.pp.ru>

On Sat, Feb 12, 2005 at 11:33:13PM +0100, holger krekel wrote:
> The good news is that I now got rid of the shallow 'yield'
> usage in favour of an old-style __iter__ implementation.  So
> the problem should be gone since rev 9174. 

   Thank you!

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.


From hpk at trillke.net  Mon Feb 14 19:18:51 2005
From: hpk at trillke.net (holger krekel)
Date: Mon, 14 Feb 2005 19:18:51 +0100
Subject: [py-dev] py.path.dict and py.path.proxy patch
In-Reply-To: <41FB196B.4040400@goldenspud.com>
References: <41FB196B.4040400@goldenspud.com>
Message-ID: <20050214181851.GC28668@solar.trillke.net>

Dear Matthew, 

sorry for taking some time ... PyPy and other stuff keeps
me busy :-) 

On Fri, Jan 28, 2005 at 23:04 -0600, Matthew Scott wrote:
> What py.path.proxy allows you to do is to take an arbitrary path and 
> create a proxy filesystem into a limited area of that path's filesystem. 
>  Maybe a better word would be sandbox, but I found proxy to be easier 
> to type.  Naming suggestions are welcome.  This code is set in fresh 
> mud, not in stone.  :)

Hehe, i like the patch and your examples.  Yet i am trying to
think of real use cases for proxy() and dict() paths.  I
guess you have some, don't you? 

> I haven't yet tried py.path.proxy using anything but py.path.local root 
> paths.

py.path.proxy() seems like a kind of a "chroot" path, btw.

> Here's an example of using py.path.proxy to wrap a directory specified 
> by py.path.local, and of using py.path.dict to create a dictionary-based 
> virtual file system that contains a copy of that directory:

Especially your dict-proxy path implementation is interesting.  IIRC, 
i have been thinking with Armin about refactoring path implementations
to work with some kind of filesystem representation as well. I think the 
idea arosed around Armin's nfs-pure-python server that works based on 
py.path, so you can basically mount certain revisions from a svn
repository, and with py.path.dict from a dictionary :-) 

A note about your patch: since a few month we have a revised 
concept for error-handling: basically all py.path.local 
(and some of the py.path.svn* stuff) will raise py.error.X 
where X == name from errno.*.  The logic to convert 
OSErrors to py.error's is in _callex() in path/common.py. 

Example: 

>>> py.path.local('/tmp/x').chdir()
------------------------------------------------------------
Traceback (most recent call last):
      File "<stdin>", line 1, in ?
  File "/home/hpk/projects/dist-vadm/py/path/local/local.py", line 306, in chdir
    self._callex(os.chdir, self.strpath)
  File "/home/hpk/projects/dist-vadm/py/path/common.py", line 216, in _callex
    raise cls, value
ENOTDIR: [Not a directory]: chdir('/tmp/x',)
>>>

This is obviously a nicely descriptive error which you can
cleanly catch via "except py.error.ENOTDIR:".  Generally
py.path implementations should now use this error mechanism to
give users a uniform way dealing with permission or semantic
problems. 

To make this error handling more transparently available i am
thinking of having a dynamically wrapped 'os' module which
error-decorates calls into os.*. maybe reachable by "py.os_x" ...
um well, probably better "py.os" :-) 

Now, if we can come up with some real life use cases i am all
for integrating your patch into the py lib nonwithstanding 
some documentation and refactorings (which shouldn't break 
the tests, though, yadda yadda).

cheers and thanks for your ideas and code!

    holger


From ianb at colorstudy.com  Thu Feb 17 06:34:29 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 16 Feb 2005 23:34:29 -0600
Subject: [py-dev] py.test test function naming
Message-ID: <42142CE5.2000701@colorstudy.com>

A note: when I was translating all my SQLObject tests into py.test, one 
issue I found is that only functions starting in test_ are found, which 
means functions (or rather methods) like testThis are ignored.  This is 
a problem, because that's the preferred style for unittest, and 
unittest-based tests are otherwise not too hard to move over (make the 
sure class name is properly named -- also a bit of a problem -- then get 
rid of the superclass and turn setUp into setup_method and tearDown into 
teardown_method).

The real problem here is that while other problems with the translation 
are usually detectable (because a test fails, or syntax is incorrect or 
something), this problem fails silently, in that a test just gets lost. 
  When converting a big project this is a problem.  So that's a 
long-winded way saying that really any method or function that starts 
with "test" (no underscore) should be picked up.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org


From hpk at trillke.net  Thu Feb 17 08:27:55 2005
From: hpk at trillke.net (holger krekel)
Date: Thu, 17 Feb 2005 08:27:55 +0100
Subject: [py-dev] py.test test function naming
In-Reply-To: <42142CE5.2000701@colorstudy.com>
References: <42142CE5.2000701@colorstudy.com>
Message-ID: <20050217072755.GC28668@solar.trillke.net>

Hi Ian, 

On Wed, Feb 16, 2005 at 23:34 -0600, Ian Bicking wrote:
> A note: when I was translating all my SQLObject tests into py.test, one 
> issue I found is that only functions starting in test_ are found, which 
> means functions (or rather methods) like testThis are ignored.

Oh, i didn't realize that 'test' is already enough for unittest.py. 
OK, I modified the trunk and the ongoing collect-branch of the py lib 
accordingly to allow for methods and functions starting with 'test' 
to be collected. 

> This is a problem, because that's the preferred style for
> unittest, and unittest-based tests are otherwise not too
> hard to move over (make the sure class name is properly
> named -- also a bit of a problem -- then get rid of the
> superclass and turn setUp into setup_method and tearDown
> into teardown_method).

That reminds me to make our tool in pypy (that does much of 
the expression-conversion) available.  It probably needs 
to be stripped from pypy-specific details, though. 

cheers & thanks for the hint!

    holger


From dialtone at divmod.com  Fri Feb 18 22:58:44 2005
From: dialtone at divmod.com (Valentino Volonghi aka Dialtone)
Date: Fri, 18 Feb 2005 22:58:44 +0100
Subject: [py-dev] Type inference documentation wanted
Message-ID: <42166514.6070909@divmod.com>

For poor people like me, pypy wannabe contributor,  I think it would be 
good to have some updated documentation about type-inference/annotation 
as done in pypy. The only doc I can find is heavily outdated, as stated 
in the first lines of the file.

Is this documentation planned?

cheers

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.3.8
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de



From hpk at trillke.net  Fri Feb 18 23:04:43 2005
From: hpk at trillke.net (holger krekel)
Date: Fri, 18 Feb 2005 23:04:43 +0100
Subject: [py-dev] Type inference documentation wanted
In-Reply-To: <42166514.6070909@divmod.com>
References: <42166514.6070909@divmod.com>
Message-ID: <20050218220443.GE28668@solar.trillke.net>

Hi Valentino! 

On Fri, Feb 18, 2005 at 22:58 +0100, Valentino Volonghi aka Dialtone wrote:
> For poor people like me, pypy wannabe contributor,  I think it would be 
> good to have some updated documentation about type-inference/annotation 
> as done in pypy. The only doc I can find is heavily outdated, as stated 
> in the first lines of the file.
> 
> Is this documentation planned?

I know it might a bit confusing but actually pypy and py are only
slightly related but not to the point where we want to do type 
inference within the py lib :-)  IOW, would you mind reposting
your question to pypy-dev? 

cheers, 

    holger


From ianb at colorstudy.com  Sat Feb 19 22:50:28 2005
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat, 19 Feb 2005 15:50:28 -0600
Subject: [py-dev] py.test reimporting modules
Message-ID: <4217B4A4.7010002@colorstudy.com>

I'm having some persistent problems with py.test and SQLObject, and 
collection errors.  SQLObject gets confused and angry when a module is 
imported twice -- for all sorts of good reasons, like two classes with 
the same name being created.

When there are collection errors -- at least some kinds of collection 
errors -- the module gets imported twice, with the same name and 
everything.  I get this kind of error message:

class Reparented1 is already in the registry
(other class is <class 
'/home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py.Reparented1'>, 
from the module 
/home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py 
in 
/home/ianb/colorstudy.com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta.py; 


attempted new class is <class 
'/home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py.Reparented1'>, 
from the module 
/home/ianb/colorstudy/com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta/py 
in 
/home/ianb/colorstudy.com/trunk/SQLObject/sqlobject/tests/test_reparent_sqlmeta.py)

(Well, I produce the error message, but it's useful information I guess 
-- the repr() of the class, the cls.__module__, and 
sys.module[cls.__module__].__file__)

I know that collection errors are a known problem, but I thought I'd 
note this one too.  --nomagic doesn't seem to cure it either.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org


From Felix.Schwarz at web.de  Sun Feb 20 18:24:42 2005
From: Felix.Schwarz at web.de (Felix Schwarz)
Date: Sun, 20 Feb 2005 18:24:42 +0100
Subject: [py-dev] unit testing error: inconsistenty failed then succeeded
Message-ID: <120475724.20050220182442@schwarz-online.org>

Hi all,

I want to start using pydev for my smaller projects but I get an error
that I do not understand. What should "inconsistenty failed then
succeeded" tell me?

I'm not a native speaker but this sounds strange to me. But beside my
problems understanding the error message I don't know why the unit
test failes at all.

>     def test_isLoginAttempt_no(self):
>             userdata = {'username' : 'foo at bar.test', 'password' : 'foobar'}
> E           login = login.Login(userdata)
> ~           (inconsistenty failed then succeeded     )
> [C:\Programme\Apache Group\Apache2\vhosts\junkkiller\cgi-bin\Fehler\test_login.p
> y:12]
> [modulepath: TestLogin.test_isLoginAttempt_no]

Minimal testcases attached.

Thanks for your help :-)

-- 
Felix
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: login.py
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20050220/fcd7c345/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test_login.py
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20050220/fcd7c345/attachment-0001.ksh>

From hpk at trillke.net  Sun Feb 20 18:54:21 2005
From: hpk at trillke.net (holger krekel)
Date: Sun, 20 Feb 2005 18:54:21 +0100
Subject: [py-dev] unit testing error: inconsistenty failed then succeeded
In-Reply-To: <120475724.20050220182442@schwarz-online.org>
References: <120475724.20050220182442@schwarz-online.org>
Message-ID: <20050220175421.GI30638@solar.trillke.net>

On Sun, Feb 20, 2005 at 18:24 +0100, Felix Schwarz wrote:
> I want to start using pydev for my smaller projects but I get an error
> that I do not understand. What should "inconsistenty failed then
> succeeded" tell me?

py.test tries to re-interpret failing expressions or statements. 
Originally we did it only for assert statements so that you can
see the exact values that evaluted to false.  We extended this 
to basically all kinds of errors but this is a bit fragile 
and can lead to the "failed then succeeded" problem: the expression 
failed originally but when we looked at it again (with our
mini-interpreter) it didn't fail anymore. Now on to your
special case: 

> I'm not a native speaker but this sounds strange to me. But beside my
> problems understanding the error message I don't know why the unit
> test failes at all.
> 
> >     def test_isLoginAttempt_no(self):
> >             userdata = {'username' : 'foo at bar.test', 'password' : 'foobar'}
> > E           login = login.Login(userdata)
> > ~           (inconsistenty failed then succeeded     )
> > [C:\Programme\Apache Group\Apache2\vhosts\junkkiller\cgi-bin\Fehler\test_login.p
> > y:12]
> > [modulepath: TestLogin.test_isLoginAttempt_no]
> 
> Minimal testcases attached.

Thanks.  If you run your test with "--nomagic" (always a good idea if 
you suspect that the test tool has problems) then you should see  

    UnboundLocalError: local variable 'login' referenced before assignment

which means: You import "login" globally but also use it as a
local name and in Python that means it's a local variable only.
Of course, then "login.Login" fails because 'login' has not been 
initialized yet as a local variable.   

However, your problem points to a limitation of our mini-interpreter
in that it probably isn't careful enough with respect to locals/globals
and compilation to prevent this kind of problem ... 

cheers, 

    holger


From Felix.Schwarz at web.de  Sun Feb 20 22:29:42 2005
From: Felix.Schwarz at web.de (Felix Schwarz)
Date: Sun, 20 Feb 2005 22:29:42 +0100
Subject: [py-dev] Re: unit testing error: inconsistenty failed then succeeded
In-Reply-To: <20050220175421.GI30638@solar.trillke.net>
References: <120475724.20050220182442@schwarz-online.org>
	<20050220175421.GI30638@solar.trillke.net>
Message-ID: <1943127717.20050220222942@schwarz-online.org>

Hi Holger,

thanks for your fast answer :-)

-- 
Felix



From hpk at trillke.net  Wed Feb 23 10:23:00 2005
From: hpk at trillke.net (holger krekel)
Date: Wed, 23 Feb 2005 10:23:00 +0100
Subject: [py-dev] py.test reimporting modules
In-Reply-To: <4217B4A4.7010002@colorstudy.com>
References: <4217B4A4.7010002@colorstudy.com>
Message-ID: <20050223092300.GJ27830@solar.trillke.net>

Hi Ian, 

On Sat, Feb 19, 2005 at 15:50 -0600, Ian Bicking wrote:
> I'm having some persistent problems with py.test and SQLObject, and 
> collection errors.  SQLObject gets confused and angry when a module is 
> imported twice -- for all sorts of good reasons, like two classes with 
> the same name being created.

Yes, i am afraid we have to revisit the importing issue in detail soon.
This week i am moving house and am otherwise pretty busy so i cannot 
look into this before next week. 

cheers, 

    holger