Making wxPython a standard module?

[John Salerno]

Just out of curiosity, what are the chances of this happening (sort of like
what happened with sqlite)? I read somewhere that Guido said the only reason
Tkinter is still the standard GUI module instead of wxPython is because "it
was there first." Perhaps a joke, but it got me thinking that there could be
a chance of this happening.

I'm sure most Python work doesn't involve GUIs, so it's not a priority, but
to have wxPython be a standard module would be great, and it might even
encourage people to play around with GUI work more than normal (I don't
think that's a bad thing!). :)

[Diez B. Roggisch]

Re: Making wxPython a standard module?

Just out of curiosity, what are the chances of this happening (sort of

like what happened with sqlite)? I read somewhere that Guido said the only
reason Tkinter is still the standard GUI module instead of wxPython is
because "it was there first." Perhaps a joke, but it got me thinking that
there could be a chance of this happening.

This has been discussed before. While tkInter might not be the greatest
toolkit out there it has two extreme advantages:

- it is comparably small regarding the footprint. Few external
dependencies, small libraries, small python-wrapping.

- it is available on a wide range of platforms.

- it is very stable, not only wrt bugs but also regarding features. There
is no external pressure to update it frequently.

- it is easily maintainable.

None of these apply to wx. It is huge, needs for example the whole GTK-libs
under linux. It is under active development, with rather frequent releases,
which means it is better to not tie it to a certain version because that
happens to be the version available when the current interpreter was
released.

For example, think of python2.4 - it has been released 4(!) years ago. It is
in wide usage. Around that time wx was at version 2.5. Now it is 2.8. So
either you upgrade wx in the subsequent released pyhton 2.4 versions - or
you are stuck with 3 minor revisions in the past, which I can only assume
are a major drawback.

And on a personal note: I find it *buttugly*. But that has nothing to do
with the reasons given above - nor do I have any weight in the decision to
include it or not... :)

Diez

[Paul Boddie]

Re: Making wxPython a standard module?

On 12 Jun, 16:18, "John Salerno" <johnj...@NOSPA Mgmail.comwrote :

Just out of curiosity, what are the chances of this happening (sort of like
what happened with sqlite)?

Plenty of prior discussion here:

http://groups.google.com/group/comp.lang.python/search?group=comp.lang.python&q=wxPython+standard+library

I doubt that the situation has changed in any significant way.

Paul

[John Salerno]

Re: Making wxPython a standard module?

"Diez B. Roggisch" <deets@nospam.w eb.dewrote in message
news:6bcqtpF3bt l4sU1@mid.uni-berlin.de...

This has been discussed before. While tkInter might not be the greatest
toolkit out there it has two extreme advantages:
>
- it is comparably small regarding the footprint. Few external
dependencies, small libraries, small python-wrapping.
>
- it is available on a wide range of platforms.
>
- it is very stable, not only wrt bugs but also regarding features.
There
is no external pressure to update it frequently.
>
- it is easily maintainable.

Ok, that was more than two advantages! :) But those are good points. I was
wondering about the size of wx too. Probably huge compared to Tkinter.

And on a personal note: I find it *buttugly*. But that has nothing to do
with the reasons given above - nor do I have any weight in the decision to
include it or not... :)

You find what ugly? The look of wxPython apps, or the code itself? To me it
seems very nice, but what do I know! I also have started using XRC (putting
the GUI in an xml file instead of in the program), so I see less of the code
clutter my program.

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: Making wxPython a standard module?

Just out of curiosity, what are the chances of this happening (sort of like

what happened with sqlite)?

As a starting point, the author(s) of wxPython would need to contribute
it to Python (and then also give the PSF the permission to relicense
it). If no such contribution is made, chances are zero. Somebody else
contributing it in place of the authors is not acceptable - that
somebody likely doesn't have the right to grant the proper license to
the PSF, and it would also meant that the in-core version of wxPython
forked from the official version, which would be unacceptable.

In addition, a group of people (not necessarily the authors) would have
to offer maintaining the in-core copy of wxPython, in the sense of
keeping it synchronized with the stand-alone release, resolving bug
reports related to the library (in particular wrt. portability), and
so on. Again, with nobody offering maintenance, chances are again zero.

For sqlite, both conditions were met, so it could be integrated.

HTH,
Martin

[s0suk3@gmail.com]

Re: Making wxPython a standard module?

I know there must be at least a few very solid answers to this, but,
just to hear it from the Pythonistas: Why can't there be several GUI
toolkits on the standard library?

[Ben Finney]

Re: Making wxPython a standard module?

s0suk3@gmail.co m writes:

I know there must be at least a few very solid answers to this, but,
just to hear it from the Pythonistas: Why can't there be several GUI
toolkits on the standard library?

Because the Zen of Python advises against it:

>>import this

The Zen of Python, by Tim Peters
…
There should be one-- and preferably only one --obvious way to do it.


--
\ "Tis more blessed to give than to receive; for example, wedding |
`\ presents." -- Henry L. Mencken |
_o__) |
Ben Finney

[s0suk3@gmail.com]

Re: Making wxPython a standard module?

On Jun 15, 9:37 am, Ben Finney <bignose+hate s-s...@benfinney. id.au>
wrote:

s0s...@gmail.co m writes:

I know there must be at least a few very solid answers to this, but,
just to hear it from the Pythonistas: Why can't there be several GUI
toolkits on the standard library?

>
Because the Zen of Python advises against it:
>

>import this

>
The Zen of Python, by Tim Peters
…
There should be one-- and preferably only one --obvious way to do it.
>

I agree with that concept. But there already is more than one way to
do it, only that the other ways are being made less accessible (by not
being on the standard library), don't you think?

Anyway, as I said earlier, I'm sure there must be very solid reasons
for this, so I don't intend to argue on this. Just a thought :).

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Re: Making wxPython a standard module?

I know there must be at least a few very solid answers to this, but,

just to hear it from the Pythonistas: Why can't there be several GUI
toolkits on the standard library?

Why do you think there can't be several GUI toolkits in the standard
library? There is nothing that prohibits such a thing per se.

See my other message on why wxPython isn't part of the standard library:
it hasn't been contributed, yet.

Regards,
Martin

[Sebastian \lunar\ Wiesner]

Re: Making wxPython a standard module?

"Martin v. Löwis" <martin@v.loewi s.de>:

>Just out of curiosity, what are the chances of this happening (sort of
>like what happened with sqlite)?

>
As a starting point, the author(s) of wxPython would need to contribute
it to Python (and then also give the PSF the permission to relicense
it). If no such contribution is made, chances are zero. Somebody else
contributing it in place of the authors is not acceptable - that
somebody likely doesn't have the right to grant the proper license to
the PSF,

If any single person can even have this right ... wxPython and wxWidgets
probably received a lot of foreign contributions along the years, and each
single contributors, whose code is still part of wx, would have to agree to
a change of license, should the PSF license be incompatible to the wx
license.

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

[Diez B. Roggisch]

Re: Making wxPython a standard module?

s0suk3@gmail.co m schrieb:

I know there must be at least a few very solid answers to this, but,
just to hear it from the Pythonistas: Why can't there be several GUI
toolkits on the standard library?

Take my first post, add martin's maintenance + licensing-issues, and
multiply the arguments by the number of toolkits you intend to include.
Then you have the reason(s).

Diez