This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nikratio
Recipients larry, nikratio, skrah
Date 2014-01-25.06:07:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1390630040.59.0.00516212719455.issue20177@psf.upfronthosting.co.za>
In-reply-to
Content
(I already sent this to python-dev, but maybe it makes more sense to have these thoughts together with the patch)

After looking at the conversion of parse_time_t_args again, I think I lost track of what we're actually gaining with this procedure. If all we need is a type that can distinguish between a valid time_t value and a default value, why don't we simply use PyObject?

In other words, what's the advantage of the extra custom strict, plus the custom C converter function, plus the custom converter python class over:

static int
PyObject_to_time_t(PyObject *obj, time_t *when)
{
     if (obj == NULL || obj == Py_None) 
         *when = time(NULL);
     else if (_PyTime_ObjectToTime_t(obj, when) == -1)
         return 0;
     return 1;
}


/*[clinic input]
time.gmtime

    seconds: object=NULL
    /
[...]

static PyObject *
time_gmtime_impl(PyModuleDef *module, PyObject *seconds)
{
    PyObject *return_value = NULL;
    time_t when;
    if(!PyObj_to_time_t(seconds, &when))
       return NULL;

[...]


To me this version looks shorter and clearer.
History
Date User Action Args
2014-01-25 06:07:20nikratiosetrecipients: + nikratio, larry, skrah
2014-01-25 06:07:20nikratiosetmessageid: <1390630040.59.0.00516212719455.issue20177@psf.upfronthosting.co.za>
2014-01-25 06:07:20nikratiolinkissue20177 messages
2014-01-25 06:07:19nikratiocreate