On 1/24/11 10:44 PM, Octavian Rasnita wrote: > Or is there a God law that tells that only Tk-based GUIs can be included > in Python?
There is no other viable option at this time for inclusion in the standard library; that's simple fact. There are options for people to write GUI's in python that are accessible. Those options do include the requirement of installing a third-party library. That's not onerous. Removing TK from the standard library at this point can't happen (at least until a theoretical Python 4K): at least not without a 100% compatible replacement which is functionally impossible (since it would have to be compatible with TK addons, too). Adding a secondary GUI framework would have to have an incredibly compelling argument behind it: and developers pledging years of maintenance in the python stdlib tree and with the python stdlib development practices, because python-dev is overworked as it is. It would need to be based on python 3.[2|3], need extensive tests and documentation in a format compatible with python.org's documentation, and solid cross-platform capability AND it be free of segfaultness, AND the more code it is the harder it is to support its inclusion, as the maintenance burden just becomes untenable-- and it would need to be PEP-8 compliant-- and-- All of that doesn't hold for wxPython. I use wxPython in my day job. I like wxPython a lot. It belongs outside of the standard library. If someone wants to devote man-years of development time to solve all of the above to make it fit the stdlib, all power to you. So far, it seems there maybe is two people who think it may be worth their time. I'm fine with installing wxPython as a third-party library. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list