RFC: wxDateTime vs Python's datetime in Phoenix

[Robin Dunn]

Hi all,

One of the things that has been on the ideas list for Phoenix since the
beginning is to not wrap the wx date and time classes, and just
automatically convert to/from Python's standard date and time classes
instead. The thought behind this is that it would remove the need to
convert to/from different datetime classes when needing to, for example,
do something like get a date from some wx widget and save it to a
database, thereby reducing complexity and confusion for the programmers.

If Python's classes had existed at the time that the calendar widget was
added to wx (this was the first thing that required the wxDateTime
class) then I probably would have just done a simple typemap at that
time and not wrapped wxDateTime at all. However after looking at it a
bit closer today I'm wondering if this is a good idea as there is not a
1:1 relationship between the available wx and python classes, and the
wxDateTime class seems much more comprehensive than Python's datetime.
While there is probably much more functionality there than almost
everybody will ever need to use, somebody somewhere probably is using it.

If I do wrap the wx classes then it will be easy to add a typemap to
automatically convert from datetime to wxDateTime when passing values to
wx methods. That will help reduce complexity a little, but may increase
confusion as any return values will still be instances of wxDateTime...

Thoughts?

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Ben Morgan]

I use it for wx.DateTime.ParseDate, which uses the current wx locale to parse free-form input. It's not perfect, but I don't think that there's a easy way to replace this using python built in.

Thanks,
Ben

--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en

[Michael Hipp]

On 2012-02-28 6:32 PM, Robin Dunn wrote:
> If Python's classes had existed at the time that the calendar widget was added
> to wx (this was the first thing that required the wxDateTime class) then I
> probably would have just done a simple typemap at that time and not wrapped
> wxDateTime at all. However after looking at it a bit closer today I'm wondering
> if this is a good idea as there is not a 1:1 relationship between the available
> wx and python classes, and the wxDateTime class seems much more comprehensive
> than Python's datetime. While there is probably much more functionality there
> than almost everybody will ever need to use, somebody somewhere probably is
> using it.

This seems like an opportunity to live out the ideal of "simple things should
be simple, complex things should be possible". The 95+% case is people just
need to get a Python DateTime into and out of some calendar control. The other
cases of needing access to the underlying wx.DateTime should be available via
the API, but not the default way to do things.

I'm sure I glossed over many messy details, but this seems like the general
direction.

Michael

[DevPlayer]

This reminds me of a discussion about wxWidget's wxFileName class. If
I remember correctly, I think a reason for not including the wxwidget
wxFileName class (or was it some -similar- file_bla_bla class) was
that Python itself already have full filename property control. I do
believe it was not a file object but a filename object or path object.

Just thinking out loud here...
While I like wxWidget/wxPython symetry (what is, what is in one is in
both, that being wxWidgets and wxPython),
I find sound logic with: "If it's in the Python standard library, and
is completely crossplatform, does it really need to be in wrapped by
wxPython? Not likely. (Although I find the wxFileName API a whole lot
prettier then the os and sys API to filenames)"

"To Be or Not to Be?" wx-ly restated: "To wrap or not to wrap? That
is the wxPython question"
Other questions to ask concerning things -like- wxDateTime or
wxFileName(and kin):
Will wrapping it with wx wrappers help the end user?

Will wrapping it make it more crossplatform or less?

Will wrapping it help the wxPython devs maintaining that wrapping or
add more work in the future?

Will the non-wrapped version gain improvements faster then the
wxPython version?

Does wrapping it give a net-gain in code clarity merely by having a
consistant coding API; such as function/method/object naming syntax
and parameter naming consitancy?

Does it conflict with Python Zen and Python coding practices; (ie.
"there's likely one best way" kinda thing)

[Sam Partington]

On 29 February 2012 00:32, Robin Dunn <ro...@alldunn.com> wrote:
(snip)

> If I do wrap the wx classes then it will be easy to add a typemap to
> automatically convert from datetime to wxDateTime when passing values to wx
> methods.  That will help reduce complexity a little, but may increase
> confusion as any return values will still be instances of wxDateTime...

IMO You should just drop the wxDateTime class. I should imagine
datetime is better tested (being more exposed to the wider world) than
wx.DateTime, and the zen of python covers this :

"There should be one-- and preferably only one --obvious way to do it."

If there is some extended functionality that you really can't do
without then we can provide it as a helper fns. e.g. in Ben's case :

(datetime, not_parsed_str) = wx.ParseDateTime(str)

Sam

[Jorge Moraleda]

Hello Robin,

I know this thread is eight years old, so I don't know what your opininion is now, but I thought I would share my thoughts as I just encountered the discussion while exploring options form converting between wx.DateTime and standard datetime.

I fully concur with all of Sam's arguments and his conclusion: In my opinion you should just drop the wxDateTime class. I think the case for this change grows stronger with time as the standard date and time classes continue adding functionality and evolving while wxDateTime does not. One notable example, which happens to be how I got introduced to this topic is timezone awareness, which is handled well in recent versions of standard datetime but not so in wx.DateTime

For the one functionality that has been mentioned that perhaps does not exist in the standard library (parsing arbitrary strings as datetime objects), there are a number of libraries devoted to it, perhaps the most well known being https://dateutil.readthedocs.io/en/stable/parser.html so there is no need to include this functionality in wxpython.

Of course changing from wx.DateTime to standard datetime is a breaking change, which in my opinion is the one strong argument against changing. Thus a change would need to be made as part of a major revision that is not backward compatible compatible and thoroughly documented including sample code. On the other hand I would expect the changes required in user code to be few and straightforward, as I would venture that virtually every user that uses dates and times is already using the standard library in their code as well.

Thank you again for wxPython. Best regards,

Jorge