plugin interface / list
hi, i'm about to write a script to play various audio files. what i want to write is a directory (module) containing wrappers around various players that supply a player object (inheriting from a general player object defined earlier) and an entry in a list of mime types (which player is for which type). i've tried various forms of import and __init__.py configurations, but i repeatedly have problems with the following steps: - create an object inheriting from the main script - fill the dictionary declared there (i guess the problem is actually the same) is there a standard way of doing such things? thanks in advance webograph -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can't timedeltas be divided?
On Thu, 25 May 2006, maric wrote: > The ratio of two durations has no meaning??? Oh, sorry, sure it has, I wanted to say "it has no meaning in timedelta provided arithmetic". It's a ratio (no dimension) not a duration. In that sense the expected result should be a float, and the proposed operator will break the timedelta's arithmetic consistence. t, u, v <- timedeltas t+u # valid t / u # valid t / u + v # invalid while all terms are valids why is this a problem? not every structure has to form a closed mathematical field, and there are other cases in which dividing similar values yields another structure (think of calculating `factor = speed2/speed1; distance2 = factor * distance1`) is there any hope this can be fixed? defining timedelta/timedelta division could not break existing code because no such division is defined yet. num_weeks = (time_diff.days * 24* 3600 + time_diff.seconds) / (7.*24*3600) this requires domain knowledge i'd expect a time structure to provide! as you can create a timedelta by timedelta(seconds=1234567), i think it is not too much to ask to have some simple way to get back the 1234567 seconds without thinking about what intervals (currently days, seconds and microseconds) are used internally. sorry for bringing up such an old thread, but this seems important to me -- up to now, there are thousands [1] of python programs that use hardcoded time calculations. regards webograph [1] http://www.google.com/codesearch?q=60|3600+24+timedelta+lang%3Apython (gave me about 2000) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can't timedeltas be divided?
On 2008-04-27 09:12, Martin v. Löwis wrote:
Last time I brought up this sort of thing, it seemed fairly unanimous
that the shortcomings of the datetime module were 'deliberate' and
would not be fixed, patch or no patch.
Ok, so then if the answer to my question is "yes", the first step
should be to discuss it on python-dev.
i've had a look at the source code and written a small patch (attached;
contains a case in classical/floor division as well as truediv).
is there a defined escalation procedure from python-list to python-dev
or should i just send the suggestion+patch there?
regards
webograph
ps: i hope the patch conforms to python c coding style (most of it is
just copy/pasted and modified).
Index: Modules/datetimemodule.c
===
--- Modules/datetimemodule.c (revision 62520)
+++ Modules/datetimemodule.c (working copy)
@@ -1656,6 +1656,30 @@
}
static PyObject *
+anydivide_timedelta_timedelta(PyDateTime_Delta *left, PyDateTime_Delta *right, PyObject* (*operator)(PyObject*, PyObject*))
+{
+ PyObject *pyus_left;
+ PyObject *pyus_right;
+ PyObject *result;
+
+ pyus_left = delta_to_microseconds(left);
+ if (pyus_left == NULL)
+ return NULL;
+
+ pyus_right = delta_to_microseconds(right);
+ if (pyus_right == NULL)
+ {
+ Py_DECREF(pyus_left);
+ return NULL;
+ }
+
+ result = operator(pyus_left, pyus_right);
+ Py_DECREF(pyus_left);
+ Py_DECREF(pyus_right);
+ return result;
+}
+
+static PyObject *
delta_add(PyObject *left, PyObject *right)
{
PyObject *result = Py_NotImplemented;
@@ -1808,6 +1832,11 @@
result = divide_timedelta_int(
(PyDateTime_Delta *)left,
right);
+ if (PyDelta_Check(right))
+ result = anydivide_timedelta_timedelta(
+ (PyDateTime_Delta *)left,
+ (PyDateTime_Delta *)right,
+ PyNumber_Divide);
}
if (result == Py_NotImplemented)
@@ -1815,6 +1844,24 @@
return result;
}
+static PyObject *
+delta_truedivide(PyObject *left, PyObject *right)
+{
+ PyObject *result = Py_NotImplemented;
+
+ if (PyDelta_Check(left)) {
+ if (PyDelta_Check(right))
+ result = anydivide_timedelta_timedelta(
+ (PyDateTime_Delta *)left,
+ (PyDateTime_Delta *)right,
+ PyNumber_TrueDivide);
+ }
+
+ if (result == Py_NotImplemented)
+ Py_INCREF(result);
+ return result;
+}
+
/* Fold in the value of the tag ("seconds", "weeks", etc) component of a
* timedelta constructor. sofar is the # of microseconds accounted for
* so far, and there are factor microseconds per current unit, the number
@@ -2147,7 +2194,7 @@
0, /*nb_inplace_xor*/
0, /*nb_inplace_or*/
delta_divide,/* nb_floor_divide */
- 0, /* nb_true_divide */
+ delta_truedivide, /* nb_true_divide */
0, /* nb_inplace_floor_divide */
0, /* nb_inplace_true_divide */
};
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why can't timedeltas be divided?
On 2008-04-27 14:18, Jon Ribbens wrote: Yes, that's where it was decided that the datetime module was fine that way it is and must not be changed. could you give me some pointers to that discussion? i found some discussion about interpretation as intervals [1], casting numbers to intervals [2] and vice versa (plus discussion of connection to unix timestamps) [3], and arithmetics of time/datetime and timedelta [4], on which i agree that those are problematic (some of those also touch the problem of time zones). nevertheless, i fail to see such problems when dividing timedeltas -- after all, `delta2 / 5 == delta1` works, so why should not `delta2 / delta1 == 5`? regards webograph [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg21629.html [2] http://mail.python.org/pipermail/python-dev/2002-March/020604.html [3] http://www.mailinglistarchive.com/[EMAIL PROTECTED]/msg12596.html [4] http://bugs.python.org/issue1118748 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why can't timedeltas be divided?
On 2008-04-27 19:28, Martin v. Löwis wrote: Post a patch to bugs.python.org, optionally also post a message referring to that patch to python-dev. i've created an issue at [1]. let's hope for the best! thanks for your support webograph [1] http://bugs.python.org/issue2706 -- http://mail.python.org/mailman/listinfo/python-list
