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...
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
···
On Wed, Feb 29, 2012 at 11:32 AM, Robin Dunn robin@alldunn.com wrote:
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…
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
···
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 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)
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 :