Code in question is cyphesis-0.5.21/tests/Py_WorldTimetest.cpp:33
  assert(PyRun_SimpleString("WorldTime(23.1)") == 0);
The python code is raising an exception:

2010-08-02T09:06:12 SCRIPT_ERROR Traceback (most recent call last):
2010-08-02T09:06:12 SCRIPT_ERROR   File "<string>", line 1, in <module>
2010-08-02T09:06:12 SCRIPT_ERROR TypeError: integer argument expected, got float

and this leads to PyRun_SimpleString returning -1 (signifying an error), rather than 0, hence the C++-level assertion fails, and dumps core.

The Python exception is coming from the WorldTime tp_init callback in cyphesis-0.5.21/rulesets/Py_WorldTime.cpp:
static int WorldTime_init(PyWorldTime * self, PyObject * args, PyObject * kwds)
B {
      int seconds;

      if (!PyArg_ParseTuple(args, "i", &seconds)) {
  =>      return -1;
      }

which is clearly requiring an int, not a float.

Did this code ever pass?

BTW, there are _lots_ of Python exceptions in the selftest logs, not just this one.

The specific exception in comment #1 appears to be this Python 2.7 change:  
  http://bugs.python.org/issue5080
i.e. the deprecation warning when passing floats became a TypeError.

Simplest fix appears to be to change:
 assert(PyRun_SimpleString("WorldTime(23.1)") == 0);
to 
 assert(PyRun_SimpleString("WorldTime(23.1)") == -1);

but I don't know to what extent cyphesis relies on this behavior.

Alternatively, if floating point with rounding is acceptable in the cyphesis Python API, then WorldTime_init should be changed.

This seems like a question for upstream; maintainer: can you contact upstream and discuss it with them please?

Relevant code is in:
http://svn.python.org/view/python/trunk/Python/getargs.c; previously it would issue a deprecation warning on floats, then call:
  PyInt_AsLong(arg);
which for a PyFloat calls float_as_number's nb_int routine, which is float_trunc, which truncates the fractional part to give the whole part as a C int.

In Python 2.7, this now raises a TypeError before attempting the conversion.

I'm forwarding this ticket to the upstream developers for guidance and/or a fix.

Sure, please also forward the 3 patches we committed.

Any updates on this? Is there a link to the upstream bug tracker where you filed the bug?

Wart, could you let us know what is the status of this package?

IIRC, it should be fairly easy to patch this so it builds, but it would be best to have the upstream cyphesis developers decide whether or not WorldTime() should be able to accept a float and silently truncate it to int.

If that's acceptable, then WorldTime_init needs a patch (which should be relatively simple to do).

One of the motivations for the change to Python 2.7 was this issue:
  http://bugs.python.org/issue5080#msg92400
where float->int truncation of a timing value led to infinite loops.

But it looks like WorldTime() has always truncated to int, so this probably wouldn't introduce new bugs.

Looks like Spot disabled the selftests:

The %changelog in cyphesis.spec in master and f14 has:

* Tue Sep 14 2010 Tom "spot" Callaway <tcallawa> - 0.5.24-1
- update to 0.5.24
- fix a few more compiler issues
- disabled tests, maintainer should fix

http://pkgs.fedoraproject.org/gitweb/?p=cyphesis.git;a=commitdiff;h=9225774be7a885a4ac2f2546eed4a3a64db5c1d5

What is the status of this? As far as I can tell, this is the only package that is not been properly ported to python-2.7. 

Wart?

I worry about this when I do the update to 0.5.26 (bug 544254). But there are some dependencies that need to get updated first.

It builds for F15. Also it for F16 and F15 testing all of the world forge libraries have been rebuilt so there shouldn't be interface mismatches.

I am not sure how to tell if detecting python2.7 is still a problem though.

Since it is building in F15+ and F14 is EOL I am going to close this.