Status of Python 3.x support?
Foogod
support in Nose..
I found a http://python-nose.googlecode.com/svn/branches/py3k/ branch,
which appears to be rather old and in an unclear development state.
I also stumbled across http://bitbucket.org/jpellerin/nose3/ , which
appears to have been another attempt on it, but unfortunately also
appears to be fairly old by this time.
I found a couple of messages here and in nose-users that suggested
that py3k support would "soon" be merged into the mainline, but they,
again, were very old, and as far as I can see this hasn't happened..
Is there something out there I'm missing? Is anybody working on
this? (Is there any interest if I put some work into it myself?) And
is there any likelihood that py3k support will eventually become part
of an official release package? (or should I not bother submitting
patches, etc, because they'll just languish in a disused branch that
nobody cares about?)
Any info would be much appreciated..
jason pellerin
situation is that I don't have any time to work on nose, and don't use
python 3 myself, so if the branch is going to ever land, someone else
will have to do the work. I've had a few people say they are
interested in working on it but nothing concrete has come out of that.
Which is the longish way of saying that if you want to take it on, go
for it. Fork the nose3 project on bitbucket, merge in the nose
project, and when your fork passes selftest for python 2.3 and above
and jython and can be packaged and installed then I'll review it and
ask at least one other nose dev to review it also, and when all is
good, it will get merged back and released. :)
JP
> --
> You received this message because you are subscribed to the Google Groups "nose-dev" group.
> To post to this group, send email to nose...@googlegroups.com.
> To unsubscribe from this group, send email to nose-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nose-dev?hl=en.
>
>
Foogod
> Which is the longish way of saying that if you want to take it on, go
> for it. Fork the nose3 project on bitbucket, merge in the nose
> project, and when your fork passes selftest for python 2.3 and above
> and jython and can be packaged and installed then I'll review it and
> ask at least one other nose dev to review it also, and when all is
> good, it will get merged back and released. :)
Actually, given the rather large volume of changes that have
apparently been applied on the main branch that would need to be
merged in, I opted to first try a slightly different approach..
I took a fork of the current codebase and spent a couple of evenings
fixing it up to make it work with Python 3.x via the 'use_2to3' option
of distribute. It's looking promising under 3.x, and should be fully
backwards-compatible with 2.x, etc.
For anyone who's interested, my branch is available at
http://bitbucket.org/foogod/python-nose3
The one big issue I have at the moment is that for some reason it's
not finding/executing any tests that are part of a unittest.TestCase
class. Unfortunately, I'm not familiar enough with how nose does all
its loader/selector/etc stuff to know how to go about troubleshooting
this. If anybody out there has any suggestions, they'd be much
appreciated..
-alex
Foogod
> The one big issue I have at the moment is that for some reason it's
> not finding/executing any tests that are part of a unittest.TestCase
> class.
The problem was a side-effect of the fact that in Python 3.x, there's
no such thing as an 'unbound method' anymore. All unbound methods are
just simple functions now, which means ismethod() returns False, so it
was ignoring all class methods when searching for tests.
The 'unbound method' issue also introduces a bunch of other annoyances
since there's now no way to find out the class name from an unbound
method by itself anymore, which a lot of the stuff assumes it can do.
I've managed to hack around this, I think, by wrapping them in a
custom UnboundMethod wrapper which provides the same functionality,
but it does mean now that they all need to get wrapped before being
passed to MethodTestCase (so I had to fix up a bunch of tests which
called that directly).
Anyway, after fixing all of that (and a few other issues discovered
now that it's loading all the tests), I'm down to 5 of 331 tests which
aren't passing (!). I'm hopeful I can knock the last few out in the
next day or two..
-alex
jason pellerin
I recall fighting with the unbound method issue myself in the nose3
fork, but I don't remember how I solved it. A wrapper seems like a
fine solution.
If this all comes together and passes selftest for 2.3->3.2, jython,
etc, I'll be very much inclined to merge your work in, do whatever
housekeeping is needed, and call that nose 1.0....
JP
Matthew Brett
On Wed, Sep 1, 2010 at 9:18 AM, jason pellerin <jpel...@gmail.com> wrote:
> Wow, awesome!
Thank you very much for doing this - it will be a huge help,
Matthew
Foogod
$ python3 selftest.py
..................................................................................................................S.........................................................................S......................................................................SSSS.............................................SS.....................
----------------------------------------------------------------------
Ran 331 tests in 4.014s
OK (SKIP=8)
FYI, skips are:
* 3 skips because Twisted is not available for 3.x (yet)
* 4 skips because the 'profile' plugin is not available (no hotshot
under 3.x)
* 1 skip of a test which was testing string exceptions (which aren't
valid under 3.x anyway)
There's a couple of minor cleanups I still want to look into, but all
indications are that nose under 3.x is basically complete!
-alex
jason pellerin
> Aaand.... tada!:
>
> $ python3 selftest.py
> ..................................................................................................................S.........................................................................S......................................................................SSSS.............................................SS.....................
> ----------------------------------------------------------------------
> Ran 331 tests in 4.014s
>
> OK (SKIP=8)
Woo!
JP
Kumar McMillan
Foogod
starting to look at the 'finesse' part of the process, I'm looking for
ways I can make the fixups a little cleaner..
Given that list sorting by key has been available since 2.4, and is
the only option in 3.x, I figure I might as well go through and update
all the list sorts that use cmp functions to use key functions instead
(so I can get rid of the ugly cmp-to-key hack I've currently got in
place), but this brings about a couple of questions:
1. Do we really need to still support 2.3? It's over 7 years old
now, and most of the other projects I know of (including big stuff
like Django) don't even support it anymore.. (I can do some hackery
to reimplement keys as cmp functions if running under 2.3, but I'm
really wondering how much value there is in it)
2. On a related note, does anything use
TestLoader.sortTestMethodsUsing? Could it be replaced with
sortTestMethodsKey or some such?
3. Does anything use the 'cmpf' argument to PluginManager.sort? I
can't find any use of it in the nose sources, but I'm not sure if this
is part of a published API or something..
-alex
Kumar McMillan
(except 2.3) at once. You can pull the change from here:
http://bitbucket.org/kumar303/python-nose3/changeset/1d763b5e492b
You need to have tox installed globally and available on the command
line. http://codespeak.net/tox/
Then you can run tox -e py31 or just run tox for all environments.
jason pellerin
> 1. Do we really need to still support 2.3? It's over 7 years old
> now, and most of the other projects I know of (including big stuff
> like Django) don't even support it anymore.. (I can do some hackery
> to reimplement keys as cmp functions if running under 2.3, but I'm
> really wondering how much value there is in it)
I can live with dropping 2.3 support, but I'd like to hear from some
other devs and users before making that decision.
> 2. On a related note, does anything use
> TestLoader.sortTestMethodsUsing? Could it be replaced with
> sortTestMethodsKey or some such?
That's coming from unittest.TestLoader. What unittest does in 2.6 and
above is use unittest._CmpToKey to convert it, if it's set, so nose
should do something similar.
> 3. Does anything use the 'cmpf' argument to PluginManager.sort? I
> can't find any use of it in the nose sources, but I'm not sure if this
> is part of a published API or something..
Doesn't seem to be used anywhere, I think it's safe to drop it.
JP
Foogod
> I can live with dropping 2.3 support, but I'd like to hear from some
> other devs and users before making that decision.
(I haven't had a chance to test it yet because I'm having a bugger of
a time getting a version of 2.3 installed on the MacOS X laptop I'm
currently using for development..) If we do drop 2.3 support later we
can go through and turn all the sort_list() calls into .sort() calls
and get rid of that bit of pyversion.py..
> > 2. On a related note, does anything use
> > TestLoader.sortTestMethodsUsing? Could it be replaced with
> > sortTestMethodsKey or some such?
>
> That's coming from unittest.TestLoader. What unittest does in 2.6 and
> above is use unittest._CmpToKey to convert it, if it's set, so nose
> should do something similar.
means we have to keep supporting it (particularly since even the
Python 3.x unittest still supports it).. I'll leave my cmp_to_key
thunk in place for that case, then.
> > 3. Does anything use the 'cmpf' argument to PluginManager.sort?
>
FYI, in my branch I've also added a new nosetests option 'py3where'.
If present, and if it's running under 3.0 or above, it will override
the default 'where' location with 'py3where' instead, so you can add
"py3where=build" to the setup.cfg and it will just automagically look
for the tests in the build directory under 3.x, and in the normal
location under 2.x..
I've also merged in Kumar's tox.ini update, and I made an extra tweak
of my own: FYI, coverage _is_ available for Python 3.x, so there's no
need to override the deps line for the py31 case.
I hadn't ever used tox before.. I'm gonna have to play around with
that a bit more at some point. (I'm still working on setting up jython
and Python <2.5 on my box, but tox seems happy with 2.5, 2.6, 2.7, and
3.1, which is encouraging :) )
-alex
Kumar McMillan
>
> I've also merged in Kumar's tox.ini update, and I made an extra tweak
> of my own: FYI, coverage _is_ available for Python 3.x, so there's no
> need to override the deps line for the py31 case.
>
aha, so it does! I remember getting a syntax error but I think that
was back when the test suite still required an older version of
coverage. By the way, thanks for updating the tests for the new
coverage output.
> I hadn't ever used tox before.. I'm gonna have to play around with
> that a bit more at some point. (I'm still working on setting up jython
> and Python <2.5 on my box, but tox seems happy with 2.5, 2.6, 2.7, and
> 3.1, which is encouraging :) )
tox is pretty neat but most useful for CI since it makes for a slower
test run. There are still some odd warnings in the Sphinx build that
I haven't looked at closely yet but otherwise all is good.
>
> -alex