[Code Challenge] WxPython versus Tkinter.

R

rusi

Good as far as it goes, but this list leaves out several requirements
(already posted by me, Steve Hansen, and others) for a Python 3 new
stdlib module. It does not matter for the stdlib if wxpython is 3 times
as good as tkinter, by some measure, as long as it is ineligible.

Thanks Terry -- so I add that to the list

Works with Python 3
Look
Nativity-1 (as in apps look like other apps on the OS)
Nativity-2 (as in uses 'bare-metal' and not a separate interpreter)
Themeing (ttk)
Efficiency (extra interpreter)
Cross Platform
Stability (crashes on some OSes)
Programmability
Accessibility
i18n
Availability of gui builder
Licence

I should have mentioned earlier (doing it now) -- it maybe better to
deal with this list breadth-first -- ie to expand it to include all
the issues rather than going depth-first into each one.
There are surely others like:
Fun to use (very important when teaching/learning but hard to
quantify)

RR: You gave equal weights to each point. This does not work in
general. eg I am chary about using a toolkit that crashes (If crashes
are ok why not use C/C++ ?)

And there is another dimension to the "breadth" which needs inclusion
-- Qt and Gtk are equally contenders with Tkinter and Wx. (Any others
Ive missed?)
 
E

Emile van Sebille

On 1/25/2011 10:08 PM Octavian Rasnita said...
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.

Emile
 
R

Robert Kern

On 1/25/2011 10:08 PM Octavian Rasnita said...

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.

That's not Terry's point. The reasons he's referring to (and stated previously)
are as follows:

1. The license of wxWidgets and wxPython is not as permissive as Python's. The
Python developers, as a matter of policy, do not want to include code into the
standard library that is less permissive than the current license.

2. The Python developers require someone to commit to maintaining contributed
code for a number of years. No one has done so. See reason #3.

3. The wxPython developers do not want wxPython in the standard library, not
least because they want to develop and release wxPython at a different pace and
release cycle than the standard library.

4. The Python developers have committed to maintaining backwards compatibility
in the standard library for a very long time. Even if they included wxPython
into the standard library, they would have to provide a Tkinter module that
works like the current one. I do not believe it is feasible to write a Tkinter
workalike that uses wxPython, so we would still be relying on Tcl/Tk.

There is certainly enough maintenance force to keep wxPython updated and ported
to Python 3, but only *outside* of the standard library.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
R

rantingrick

---------------------------------------
 Challenge 1: (Simple Directory Viewer)
---------------------------------------

Create a simple Directory Viewer GUI. You CANNOT use a treectrl!  The
point of this challenge is to show that Tkinter has no support for a
true ListCtrl widget. However the Wx::ListCtrl is fully featured! For
wxPython the code is simply wielding a few built in classes. For
Tkinter no such ListCtrl functionality exists. You CAN create the
functionality yourself (and i know this because i HAVE created it!)
however it involves tons of work and still can't hold a candle to the
wx::ListCtrl

---------------
 Requirements:
---------------

How the user navigates to a folder is not important but you must
display the list of files/folders in two view modes with icons;

 1. Display files in both ReportView and ListView.

  * Reportview:
    ...scrollable vertical list with three columns.

  * Listview:
    ...scrollable horizontal-ly wrapping list.

Note: If you do not understand the view modes just run my code for an
example. But the user must be able to switch between these two modes
easily. How the switching is done is unimportant -- I simply used two
buttons.

 2. Columns
  * Minimum of three cols; Name, Size, and Type (reportview).
  * the "Name" column must include an icon AND label (both views).
  * columns must be sortable by the user (reportview).
  * columns must be sizable by the user (reportview).

 3. Items
  * All must be editable in place (no popup editing allowed!).
  * All items must be selectable/deselectable by user.
  * All items must be delete-able by the user.

That is the challenge. Step forth and battle if you can!

-----------------
 WxPython code:
-----------------

https://sites.google.com/site/thefutureofpython/home/code-challenges

I await any challengers...


So we have come this far and still not one challenger. Neither can one
person admit that the wxPython ListCtrl is far superior than widget
TclTk contains. But that really does not matter now. The point is that
TclTk have grown stagnate and have been that way for many years.
Whilst Tkinter does sport a beautiful API we have no way to scale the
module because TclTk is limited. New Python programmers will start out
(like i did) with Tkinter and love its simplicity, however eventually
they will come to understand that all their spend energy writing
Tkinter has been for nothing. They will realize that Tkinter is 1990's
technology migrated into the 21st century. That is point i am making.
Some people can handle the truth. Denial is to be expected.

If you are out there and your not one of the redundant trolls who keep
parroting off and assassination my character please drop by and insert
your opinion on the value of Tkinter. Just make sure to use facts and
not emotion driven drivel. If you choose to be a troll i cannot stop
you, and i would not. However i will not respond to trollish posts
anymore. It is quite clear that a hand full of the same old folks want
to stop me at all costs -- even at the expense of their own soul.
Psst: If you notice they are not yelling about the code anymore
because it is bug free. They are only interested in spreading
discontent and not solving problems. That is a blindingly apparent
fact.

Anyway i still await a solid challenge. Either in code or in words
based on facts. Until then i will consider myself victorious by
default.
 
O

Octavian Rasnita

From: "Emile van Sebille said:
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.

Emile



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.

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?

I don't know why, but I have a feeling that even in these cases WxPython is still not wanted and I don't understand why.

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?
What do you think it is more important, to offer accessibility for most of the users, or to create small applications?
(Note that I didn't say that Tkinter should be forbidden, so if somebody in some edge cases need to make a very small program, he/she could do it very well.)

So I still don't understand why WxPython wouldn't be prefered even all its problems would be solved.

Octavian
 
O

Octavian Rasnita

From: "Robert Kern said:
That's not Terry's point. The reasons he's referring to (and stated previously)
are as follows:

1. The license of wxWidgets and wxPython is not as permissive as Python's. The
Python developers, as a matter of policy, do not want to include code into the
standard library that is less permissive than the current license.

This is the worst and... sorry for the word, but real stupid thing.
I mean, I don't consider a correct thinking to care more about the permissiveness of a licence which is anyway open source, more than about the accessibility.
Try to think that for some people Tkinter displays just a black filled rectangle. In that case would you still think that it is "correct" to keep that kind of GUI because of some differences between open source licences?

2. The Python developers require someone to commit to maintaining contributed
code for a number of years. No one has done so. See reason #3.

In that case I understand that there are enough WxPython developers, well funded, but there is no commitment from them.
From Python's perspective, there are not enough maintainers that can offer that commitment and yes, this is a real reason why the core Python developers can't include WxPython.
3. The wxPython developers do not want wxPython in the standard library, not
least because they want to develop and release wxPython at a different pace and
release cycle than the standard library.

From the message of a list member which (but maybe I am wrong) appear to be a WxPython developer, I suspected that the WxPython developers might not want their work to be included in the Python distribution.
I am not really sure about this because I haven't seen any message from a WxPython developer telling that yes, I am a WxPython developer and we don't want to allow including WxPython in the Python distro, and I almost don't believe that, but if it is true, I don't know why they didn't said that, because WxPython is their work and of course that if they don't accept to maintain a WxPython as apart of Python distribution, then this discussion doesn't have any meaning.

I have only heard that WxPython will never be included, but without beeing more clear.

Who knows, maybe some of those who said that are WxPython developers but for me they are just some names because I don't know them...

The next (or previous) points are not important anymore if the WxPython developers don't want their work to be included in the Python distribution.

So, is it true? That was the cause for which WxPython can't be promoted by Python? Because the WxPython developers don't want this?

If the answer is yes, then too bad, because as I said, it's their work and they can do whatever they like with it.

Octavian
 
R

rantingrick

On 1/26/11 10:00 AM, Emile van Sebille wrote:
That's not Terry's point. The reasons he's referring to (and stated previously)
are as follows:

1. The license of wxWidgets and wxPython is not as permissive as Python's.. The
Python developers, as a matter of policy, do not want to include code into the
standard library that is less permissive than the current license.

This is actually a weak argument and i'll explain why. GUI libraries
are very complicated and time consuming projects. Just think of all
the work involved just to get a library working on one platform...
much less THREE or more platforms! And while i am a huge believer in
100% open source software you've got to understand why most libraries
are restrictive for commercial usage or worse. Yes TclTk IS fully
opensource and i applaud them for it! However like the old adage say:
"You get what you pay for".
2. The Python developers require someone to commit to maintaining contributed
code for a number of years. No one has done so. See reason #3.

3. The wxPython developers do not want wxPython in the standard library, not
least because they want to develop and release wxPython at a different pace and
release cycle than the standard library.

I have already shown why this does not matter. The current wxPython
API is NOT good for Python. We DO NOT want segfaults and "C++ looking"
code written by the users of a Python stdlib module. Robin has stated
that there exists room for an abstraction layer on top of wxPython and
he is correct. He has also stated that he wants to keep "his wxPython"
as close to WxWidgets as possible. So be it! We will never want to
include wxPython "proper" in the stdlib anyway because it is SO
unpythonic!! No. All we have to do is create an abstraction API that
calls wxPython until we can create OUR OWN wxPython from WxWidgets.
Call it Wxpy if you like.
4. The Python developers have committed to maintaining backwards compatibility
in the standard library for a very long time. Even if they included wxPython
into the standard library, they would have to provide a Tkinter module that
works like the current one. I do not believe it is feasible to write a Tkinter
workalike that uses wxPython, so we would still be relying on Tcl/Tk.

Fine support Tkinter until Python4000 i don't care. But we must move
forward. We must accept that Tkinter is already legacy and there is no
moving forward now. We will support Tkinter for backwards
compadibility however we will start to integrate a truly Pythonic
WxPython abstraction API and include just the API module in the
stdlib. Then we don't have to maintain a huge library, just a small
module with a wxPython 3rd party dependency. Then at some point in the
future when the stdlib is ripe, we can THEN include some form of
wxWidgets, and dump Tkinter forever. At least then we would be moving
towards something. Currently we are stagnate.
There is certainly enough maintenance force to keep wxPython updated and ported
to Python 3, but only *outside* of the standard library.

So let wxPython due what wxPython does best. We will use them as long
as we need until we can create a stdlib compliant wxPython ourselves.
They would be fools not to work with us! Because eventually when no
3rd party download is needed, all their work would go into the bit
bucket. I doubt Robin is that foolish. He seems like a smart fellow to
me -- even though he refuses to comply with PEP8 :)



SUMMARY: We create an abstraction API atop "Robin's WxPython". We
include only the API in the stdlib at this time and we keep Tkinter in
maintenance. Then over the next few years we start a fresh wxPython
project that will be acceptable for the stdlib. Something that we can
plug our API into. We steal as much from Robin as we can (or get him
to cooperate). Then when the time is right, we dump Tkinter and
integrate the new Wxpy module into the stdlib. Then we will be back on
track.
 
R

Robert Kern

This is the worst and... sorry for the word, but real stupid thing.
I mean, I don't consider a correct thinking to care more about the permissiveness of a licence which is anyway open source, more than about the accessibility.

Being able to say that all of a project is available under the substantively the
same license is really important. It's very hard to get people to use your
software if some parts are under one license and other parts are under a
substantively different one. You are free to decide what licenses you want to
distribute software under; the PSF has that freedom as well.
Try to think that for some people Tkinter displays just a black filled rectangle. In that case would you still think that it is "correct" to keep that kind of GUI because of some differences between open source licences?

This is a reason for application developers to use wxPython, not for the Python
developers to include wxPython in the standard library. The standard library
neither claims nor aims to do everything. There are many things that Tkinter
cannot do that wxPython can. None of those things are reasons to replace Tkinter
with wxPython in the standard library. Not everything useful has to be in the
standard library. Python has a vibrant ecosystem of third party packages.

wxPython is probably the most widely used GUI toolkit in Python. It has not been
harmed (and I would argue that it has been very much helped) by not being in the
standard library. Nor has it been harmed by the presence of Tkinter in the
standard library. If wxPython had been included in the Python standard library,
it would not have been able to easily follow the advancements of the underlying
wxWidgets toolkit, and it would be a much less strong GUI toolkit.
In that case I understand that there are enough WxPython developers, well funded, but there is no commitment from them.

Correct, they have not committed to maintaining wxPython as part of the standard
library (although they are committed to maintaining wxPython outside of it).
They have not even suggested that wxPython should be part of the standard library.
I am not really sure about this because I haven't seen any message from a WxPython developer telling that yes, I am a WxPython developer and we don't want to allow including WxPython in the Python distro, and I almost don't believe that, but if it is true, I don't know why they didn't said that, because WxPython is their work and of course that if they don't accept to maintain a WxPython as apart of Python distribution, then this discussion doesn't have any meaning.

Robin, if you're still paying attention to this thread, would you mind chiming
in? Robin Dunn is the wxPython project lead.
I have only heard that WxPython will never be included, but without beeing more clear.
Who knows, maybe some of those who said that are WxPython developers but for me they are just some names because I don't know them...

The next (or previous) points are not important anymore if the WxPython developers don't want their work to be included in the Python distribution.

So, is it true? That was the cause for which WxPython can't be promoted by Python?

There is a large difference between the being "promoted by Python" and being
"included in Python's standard library. The latter is the issue at hand, not the
former. wxPython is already "promoted" by Python's documentation:

http://docs.python.org/library/othergui.html

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
R

Robert Kern

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.

No, you are misrepresenting what was said. What is required is that someone make
an active commitment to maintain wxPython as part of the standard library
*specifically*. That means that the package has to follow Python's release
cycle. The wxPython developers do not wish to do that. They can develop wxPython
much better outside of the standard library.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
R

rusi

Heck, I am probably wasting my time with this post; but you come across
as genuine in your held central beliefs, and so either serious or the
most dedicated and adept troll I have ever encountered. In the case of
the former, I hold an optimistic view that most people are capable of
self-asessment. In the case of the latter, consider me successfully trolled.

RR: I'd just like to add -- Do consider whom your verbal violence
hurts most.
You may also want to google for Erik Naggum
 
R

rantingrick

I look forward to reading your PEP and initial design documents, though
I suspect you would need the latter and to get some a decent portion of
work done before it would even be considered as an inclusion into the
standard library.

Yes i want to create an API similar to Tkinter but we cannot mirror
exactly Tkinter because wx takes a completely different approach to
GUI building. We need to steal all the good attributes of Tkinter (and
there are quite a few!), learn from them, and evolve the next
generation of API. Tkinter will not be a waste because we will stand
on the shoulders of Tkinter and reach even higher! Some of the
worthwhile "must haves" are:

* Geometry managers (pack, place, grid)

The geometry managers of Tkinter are just too beautiful to let die. Wx
forces you to use Sizers which are a terrible obstacle to the new GUI
programmer. And if you want focus traversal then you must also use
Panels. This multiplicity is just too ugly for a high level API like i
am suggesting. We will need some auto generation of panels and easier
to use Sizers wrapped up in a nice Tkinter Geometry Manager like API.
This will take some work. However it can be done.

* Tagging systems for a TextCtrl and Canvas.

Although i challenged Guido on his argument about tagging, i do much
agree that tagging is a *very* powerful feature of the TK::Text and
TK::Canvas widgets and we should no doubt incorporate this into the
API. And this would be one of the easier aspects of the design.

* Event binding

Here is another area for improvement. While wx has been moving towards
a more "Tkinter like" binding of widget events there is still much to
be desired. However the binding is not all bad so we should not spend
too much time here if only for very small payoffs.

* Segfaults

We must protect Python users from segfaults. This is really a
wxPython's problem however we could insulate the programmer through
many techniques on our end. Like for instance: Recreating the columns
of a list control after configuration of a single style. However
configuration needs a look at also!

* Styles

One of the things that always bothered me about Tkinter was lack of
styles. I know this has been addressed however in the past one would
create many widgets that should share a similar style but Tkinter
forced you to feed redundant style options to all of them. We need a
way to create style objects and then use them everywhere. I think wx
supports this already.

This is just a very meager list. Much more needs consideration.
However this would be a good launch point toward some stated and
attainable goals. There is already a quite mature (citaion needed)
start with a project called wax. Check it out here...

http://wiki.wxpython.org/Wax

Many capable developers have
their own occupations and might not have the spare time or desire to
spend on a project where all evidence suggests would be a
(non-benevolent) dictatorship where they would be endlessly browbeaten.

Well i don't want to be a dictator. I believe that in any healthy
community, every member should be a king, however no ONE member ever
wears the crown. What i mean is, everyone has a special skill that
makes them stand out from the crowd. Something that you do better than
the other members. So when the needs of my skill-set are present, i
will step forth and lead, and when the needs of your skill-set are
present, i will sit back and listen and follow YOUR lead. This is how
the strongest groups tackle the largest problems with ease.
You have continuously tried to outright present yourself as a
'visionary' and speaker for the python community and then asked why
people don't take you seriously. People would take you a lot more
seriously if you showed that you had the vision and capability to drive
development of such a serious undertaking, and manage such a team of
developers, whom you have first managed to attract to the project.

Agreed, and i hope to demonstrate these skills soon. However like i
mentioned in my last statement, i am not a god, much less a dictator.
No single man or woman can accomplish these huge problems alone. It
takes a team of united folks all simultaneousness willing to lead AND
follow when the time is right for the greater good of a common goal.
  - Write some design documents, or even code, laying out what you think
the interface should be.
  - Put it out to the community, listen to advice, make changes (it will
NOT be perfect) and gather support.

I believe we are in this stage now. However much more discussion is
needed.
 
S

Stephen Hansen

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/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNQH8LAAoJEKcbwptVWx/l4OoH/j7mpOGM7eFpASixgrx+Jsbd
Ar6Jt0rFrET9DaqLnXx079rAdaxuroQKapnbVnhgDjbgDK382lGpbAnI78LSZRZw
snfKgL2JW4q0tq6EhJzUMGUgeah9+6saGEwdVqLsnIIOoycKR4ol+MPyprfpciNX
QOAfyj77zX4X/5iF2QoH9M/dGa4XULrzZbPuKuaDDBU0Epc83Rp1n+qLqCF2EsMn
nhgAgVYxt3qjIyWDpW2hrCMrUcZ39I9V26zjTUf8mmNJNGN32gu7jKxjmi0B/8kD
ouBFH90OXX2NRIlKd5jQdZcAJ4sP73UIE/wMngi2q5yIadjJANHhZgUSsvjkDqI=
=UayU
-----END PGP SIGNATURE-----
 
R

rantingrick

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.

Stephen "Strawman" Hansen: If he only had a brain! :)

That is the most obvious straw-man to date in this thread. What about
the large portion of folks who don't use all the datatypes (queue,
weakref, etc) or how about numeric and math modules (fractions,
decimal, etc) or how about data persistence, or Cryptograhic, or
curses! or, multimedia services, or, or.

You see NOT everyone uses everything in the stdlib and most use much
less than half. However we would be fools to claim "batteries
included" and NOT support GUI!
 
B

Bryan

Stephen "Strawman" Hansen: If he only had a brain! :)

That is the most obvious straw-man to date in this thread. What about
the large portion of folks who don't use all the datatypes (queue,
weakref, etc) or how about numeric and math modules (fractions,
decimal, etc) or how about data persistence, or Cryptograhic, or
curses! or, multimedia services, or, or.

You see NOT everyone uses everything in the stdlib and most use much
less than half. However we would be fools to claim "batteries
included" and NOT support GUI!

You show a remarkable, awe-inspiring ability to completely miss every
salient point of a well articulated argument.
 
T

Terry Reedy

That's not Terry's point. The reasons he's referring to (and stated
previously) are as follows:

1. The license of wxWidgets and wxPython is not as permissive as
Python's. The Python developers, as a matter of policy, do not want to
include code into the standard library that is less permissive than the
current license.

2. The Python developers require someone to commit to maintaining
contributed code for a number of years. No one has done so. See reason #3.

3. The wxPython developers do not want wxPython in the standard library,
not least because they want to develop and release wxPython at a
different pace and release cycle than the standard library.

4. The Python developers have committed to maintaining backwards
compatibility in the standard library for a very long time. Even if they
included wxPython into the standard library, they would have to provide
a Tkinter module that works like the current one. I do not believe it is
feasible to write a Tkinter workalike that uses wxPython, so we would
still be relying on Tcl/Tk.

Yes, very well put.

Another point is non-gui baggage. In my opinion, and I suspect others,
this should be minimal to absent.

Tk itself is purely a gui package -- abstract widgits, geometry placers
to make them visible, and an event system to make them active. But it
does have the baggage of needing tcl included. About a decade ago, some
people had the idea of removing the tcl dependency, but nothing seems to
have come of that. For some people, the tcl baggage is reason enough to
be rid of tk.

Qt, in contrast to tk, is not a gui package, but an application
framework and library that includes QtGui as one of about 10 modules.
There is also, for instance QtSockets and QtScript (now included in
QtCore). Qt as a whole could not go into the stdlib.

From what I remember when I looked at the WxWidgets feature list some
years ago, WxWidgets does not come with a scripting language, but also
has more that strictly gui stuff. So I think it would also need to be
subsetted.

PyGui seems to be purely a gui package, but it appear to be aimed only
at 2.x with no interest in 3.x.
There is certainly enough maintenance force to keep wxPython updated and
ported to Python 3, but only *outside* of the standard library.

I got the opposite impression from the link above. As of last May, 3.x
support is deferred until a new C++ code generator is written, and that
is deferred until new features are added and released. So it seems the
project needs another person to either code the new code generator or
learn how to port Capi code (or both). Since there is no 2to3 for Capi
(as opposed to Python code), I do not even know is a single code base is
possible. I am sure that whoever works on a wxPython port could learn
from whoever did the numpy port.
 
L

Littlefield, Tyler

Stephen "Strawman" Hansen: If he only had a brain!
And you want -us- to take -you- seriously? Tell me, what did you
accomplish with that insult? Beyond elevating your own ego and trolling
some more, anyway.
 
S

Stephen Hansen

Stephen "Strawman" Hansen: If he only had a brain! :)

That is the most obvious straw-man to date in this thread. What about
the large portion of folks who don't use all the datatypes (queue,
weakref, etc) or how about numeric and math modules (fractions,
decimal, etc) or how about data persistence, or Cryptograhic, or
curses! or, multimedia services, or, or.

You see NOT everyone uses everything in the stdlib and most use much
less than half. However we would be fools to claim "batteries
included" and NOT support GUI!

As usual, you selectively quote and completely miss the point.

Hint: the quoted portion was not an argument for or against inclusion of
anything.

The funny thing is, by selectively quoting the phrase and using it to
imply that I was making a straw-man argument against inclusion with that
statement -- which, point of fact, I was not -- you are yourself, making
a straw-man argument.

http://en.wikipedia.org/wiki/Straw_man
"To "attack a straw man" is to create the illusion of having refuted a
proposition by substituting it with a superficially similar yet
unequivalent proposition (the "straw man"), and refuting it, without
ever having actually refuted the original position."

I can't decide if you're just ignorant or if you're an artful troll with
a sense of irony and did it on purpose.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNQK3MAAoJEKcbwptVWx/l2eYIAKy+8eegExLAwICWuJRs4LZJ
ZSj4KestcA9g50l6PJtPzopH8oZYwcCUQTAqIjNZoxVnjrBche8ghyYYEt0GloZO
NpnpE1u+Y0mTgG4+qq0qCx0vlFqB0lf8ehJEXhaWoqx8iiXYBWu7cML2MDiCM5B+
Fo20iS6lFwPFQ2e817z/KIs2ysZuO0mVRCgictmfnjE1HgPqRUJ/ow+XN9JzLHkr
VarHl6dkXPRgcarve3R8Ch0vWntJH78Rc3VlXmw6tWZEyiJvhx8grXX5wyIWQR9k
QlbGmrpUBwadIq9wXxlkIXhzdRh5qE0IQ46EgYjmMiInIO8vJurexjb+lWQ+CCg=
=LsH7
-----END PGP SIGNATURE-----
 
R

rantingrick

PyGui seems to be purely a gui package, but it appear to be aimed only
at 2.x with no interest in 3.x.

I really like pyGUI. We would have to do a ton of work to get it even
to the scale of Tkinter. In hindsight the project seems like something
Python should have considered from the beginning. Had we have started
with something like pyGUI 20 years ago, i'd bet we would be better off
today since we could control the development internally.

PROS:

* small
* cross platform??
* pythonic
* under our control
* unlimited possibilities

CONS:

* not feature rich
* huge amount of work needed

Although pyGUI would probably never measure up to wxPython. I still
have a special place in my heart for such an ambitious and visionary
undertaking. You can read the goals at Greg's site. Every time i do i
get a tear in my eye thinking of the possibilities.

http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
 
R

Robert Kern

From what I remember when I looked at the WxWidgets feature list some years
ago, WxWidgets does not come with a scripting language, but also has more that
strictly gui stuff. So I think it would also need to be subsetted.

For what it's worth, wxPython tries not to wrap parts of wxWidgets that can be
replicated by the standard library. I do believe they wrap some non-GUI parts of
wxWidgets that are needed to work with certain GUI widgets, but don't quote me
on that.
I got the opposite impression from the link above. As of last May, 3.x support
is deferred until a new C++ code generator is written, and that is deferred
until new features are added and released. So it seems the project needs another
person to either code the new code generator or learn how to port Capi code (or
both). Since there is no 2to3 for Capi (as opposed to Python code), I do not
even know is a single code base is possible. I am sure that whoever works on a
wxPython port could learn from whoever did the numpy port.

In loose terms, what we learned from the experience was that it actually isn't
so bad once you knuckle down to it. But yes, it does look like some more
volunteer effort would be needed to get Python 3 support soon. I note that I did
not specify any particular deadline. :) I just wanted to disabuse Octavian of
the idea that we are claiming that the wxPython team is inadequate in general.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
T

Terry Reedy

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?

This would be a 'split', not a 'fork' (important difference).

There are really two ideas here.

1. As many modules as possible would have a pure Python reference
implementation. Any implementation could use that until it choose to
replace or supplement with a native-language implementation.

For instance, itertools in coded in C for speed, but the docs give
Python (near) equivalents for clarity. A common Python stdlib would have
a Python-coded itertools. CPython would actually run the C-coded
equivalent renamed _itertools.

Maintaining both versions in parallel would be more work, so this could
only happen if other implementors chipped in to help.

Stephen, you are the first I know of to ask whether such a project would
affect addition of new modules. Hard to say.


2. Separate tests that test compliance with the Python specs (for both
language and stdlib) from tests that test implementation-specific
behaviors. The current CPython test suite mixes both together. If
separated, other implementations could (and would) use the Python tests,
and their people would be more willing to help improve the Python tests.
Many stdlib modules are not at 100% coverage and need expansion.

For instance, "1+1 == 2" tests Python behavior, while "a,b=1,1;
id(a)==id(b)" tests a CPython implementation detail. Last I knew, both
types of tests are in the same test file.

Reference count tests, for example, are also CPython-specific.


Both of these ideas will be looked at after the hg migration.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top