On 1/26/11 9:19 AM, Octavian Rasnita wrote: > From: "Emile van Sebille" <em...@fenx.com> > ... >>> Well, I didn't know this, and it is a valid reason. >>> This means that it is true that there is no enough maintainance force to >>> keep WxPython updated. >>> Did I understand correctly? >> >> Not at all -- wxPython is an active funded ongoing project. Review the >> roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly >> the final paragraph on Python3.x support. > > But somebody said that the core Python developers, or Guido said that > WxPython won't be included in the core distribution because it doesn't have a > strong team of maintainers... with other words but this was the idea.
That isn't, at all, what people said. What they said was that for a new library to be included in the stdlib, it must have maintainers willing to *commit* for years to *maintain* it IN the stdlib. Maintaining something in the stdlib is very different then maintaining something out of the stdlib. The stdlib has quite a few rules: and it evolves at a certain set speed. wxPython is a wrapper around a third-party library which evolves at a totally different rate: if wxPython were included in the stdlib, these two completely separate development cycles could result in significant hardship for the maintainers and more importantly, for the USERS. Does Python now hold up a release waiting for the wxWidgets team to put out a new version with great new features? Or, does Python release as normal, and just by happenstance does wxWidgets release a great new release a month later-- and now Python users can't get it for a year or two when the next feature release of Python is available? Either way, the maintainers job is more difficult, and users are harmed. There's a reason that libs that go into the stdlib tend to be very static and extremely slow paced in their evolution. Now, Robin could decide to maintain wxPython in two places: as a third-party library, and every release cycle sync in the latest to the core stdlib. That's been done: but its actually extremely problematic itself, and is asking for a lot of extra work. wxPython as a third-party library is maintained: certainly. But that doesn't mean wxPython in the stdlib would be maintained. Then again, it may be that they would be fine with moving into the stdlib-- but since its not a viable option for numerous other reasons, they never bothered to give it any real consideration. > So I still don't understand why WxPython can't be a good solution. > If WxPython is well maintained, let's pretend that the maintainers solved > that bug that make the apps give a segfault, and let's pretend that it works > under Python 3. > Can it be a good choice for replacing Tkinter? That's hand-waving a LOT of stuff with "let's pretend", but okay. Let's pretend that the lib is modified and fixed up so that segfaults don't happen (and, IIUC, the next version may be); and let's pretend it works under Python 3 (does that leave me in the dust, as someone who would love to get some wxPython updates but who is only using Python 2.5?). There's a bunch of hurdles that would need solving before its a candidate for inclusion: (off the top of my head) 1. Tkinter can not be removed without a 100% compatible replacement for the forseeable future. 100%. No exception on that 100%. This includes people downloading TK extensions and using them in their Python apps: because if thats not possible, real applications will fail. Please understand before you move on. This is one of the hurdles of the stdlib that make maintaining something in it harder then maintaining something out of it: there are strict compatibility requirements and rules. It might be a great thing for humanity to have Python include an accessible GUI toolkit in the standard library: but that doesn't mean the rules can be broken in doing it. Since its basically impossible to be compatible as such, what you'd have to do is add wx while leaving tk, not replacing it. So: 2. New additions must be PEP-8 compliant; wx is not. 3. New additions must include unit tests; I actually don't know if wx does. I've always found it a pain in the butt to test GUI stuff-- but TK is tested (to some degree, I'm not sure how good the coverage is: I just remember tweaking my buildslave to make it run the tests :)). 4. The documentation would have to all be totally rewritten to fit the stdlib documentation format 5. The license thing needs solving from a legal standpoint (new code is traditionally donated to the PSF under the Apache license, which then in turn re-licenses the code under the Python license). You may think its stupid to let something like that get in the way, but sorry: we live in a lawyer's world. 6. Someone would have to commit to maintaining it _in_ the stdlib. 7. Someone would have to work on integrating the wx build requirements with the stdlib's build requirements for all the platforms -- and this can be quite a bit. If this makes the release maintainers jobs a lot harder ... well, they may need some more hands on deck. ... and more. There's a lot of work there. A lot. A lot a lot. And that's just hand-waving away some really significant obstacles with Let's Pretend. Besides: did you know a not insignificant number of people would like to do away with the stdlib in its entirety? And, more then a few actually are pushing for the stdlib to be forked off of CPython, and instead end up shared by all the major Python implementations (CPython, Jython, PyPy, IronPython, what else?) as a common resource? Not saying either group would win (though the latter sounds like a very cool thing to me), but what does either say about the implication of including wxPython? > I can see that the people try to find some false arguments like the one that > WxPython is bigger than Tkinter, but really, who cares today about a few > aditional megabytes? I'm sorry, but you're confusing what you care about with what other people care about. You do it a lot. But you seem actually honest in your efforts, so I give you the benefit of the doubt. Size does matter to some people, and legitimately so. Still others care deeply about what is bundled with Python because they're in environments where installing third-party libraries isn't allowed: these two interests can stand in opposition to one-another, but that does not make either /false/, and it does not mean that either is /right/. There are many interests involved in a language like Python which has broad usage in extremely varied fields and endeavors: most of which never come near this list. And some people have absolutely no need-- no need at all-- for any sort of GUI programming at all. This group is actually really, really big. The argument is not false: for YOU it is not compelling, and hell, for me I don't find it compelling either. But it is a valid issue which has to be weighed and taken into consideration. Maybe after that is done, on balance, its deemed to be not that big of a deal. But maybe when added up with other concerns, it is. > What do you think it is more important, to offer accessibility for most of > the users, or to create small applications? I think its important to do both. And wxPython living on in a third-party library fits that perfectly well. -- 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
