tk package added to PEP 3108
I added the proposed tk package. I did merging of the modules with similar names but with or without a 'tk' prefix. Might be able to toss some out, but since I never use Tkinter I am not going to bother.
-Brett
On Feb 24, 2008, at 1:12 AM, Brett Cannon wrote:
I added the proposed tk package. I did merging of the modules with similar names but with or without a 'tk' prefix. Might be able to toss some out, but since I never use Tkinter I am not going to bother.
The specific re-naming proposals sound reasonable to me, though it's been a long time since I've used Tkinter.
The open issue you added to the PEP, regarding removing Tkinter (by whatever name) from the core, allowing it to be independently maintained, makes a lot of sense. Tk isn't used so much on Unix/Linux as it once was, and has never received a great welcome on Windows. The rationale for removing it, allowing it to more closely follow Tk, makes a lot of sense to me as well.
And that would make the standard library smaller, and easier to maintain. Always a good thing.
-Fred
On Sun, Feb 24, 2008 at 12:37 AM, Fred Drake fdrake@acm.org wrote:
On Feb 24, 2008, at 1:12 AM, Brett Cannon wrote:
I added the proposed tk package. I did merging of the modules with similar names but with or without a 'tk' prefix. Might be able to toss some out, but since I never use Tkinter I am not going to bother.
The specific re-naming proposals sound reasonable to me, though it's been a long time since I've used Tkinter.
The open issue you added to the PEP, regarding removing Tkinter (by whatever name) from the core, allowing it to be independently maintained, makes a lot of sense. Tk isn't used so much on Unix/Linux as it once was, and has never received a great welcome on Windows. The rationale for removing it, allowing it to more closely follow Tk, makes a lot of sense to me as well.
And that would make the standard library smaller, and easier to maintain. Always a good thing.
That all sounds reasonable (and the reason I think it is a good idea), but convincing python-dev in general might be tough. Especially since that would cause IDLE to not be part of the stdlib.
-Brett
On Feb 24, 2008, at 4:11 AM, Brett Cannon wrote:
That all sounds reasonable (and the reason I think it is a good idea), but convincing python-dev in general might be tough. Especially since that would cause IDLE to not be part of the stdlib.
I've no hope of convincing python-dev myself; the response to my suggestion about moving email out was... disappointing. I just don't have the time needed to champion any large changes these days, and a "Lean Python" is a hard sell.
-Fred
On Sun, Feb 24, 2008 at 9:57 AM, Fred Drake fdrake@acm.org wrote:
On Feb 24, 2008, at 4:11 AM, Brett Cannon wrote:
That all sounds reasonable (and the reason I think it is a good idea), but convincing python-dev in general might be tough. Especially since that would cause IDLE to not be part of the stdlib.
I've no hope of convincing python-dev myself; the response to my suggestion about moving email out was... disappointing. I just don't have the time needed to champion any large changes these days, and a "Lean Python" is a hard sell.
It is definitely a hard sell. There is a reason this is the third time I am trying to reorganize everything. =) I think the "batteries included" philosophy is too heavily ingrained in the community to ever let us take large strides towards being more like Perl. Getting rid of anything is going to require that it be obsolete or so externally tied to something that it is just more practical to move it out. Otherwise the chances of taking something out (e.g., email) is going to be damn near impossible.
-Brett
On 2008-02-24 20:42, Brett Cannon wrote:
On Sun, Feb 24, 2008 at 9:57 AM, Fred Drake fdrake@acm.org wrote:
On Feb 24, 2008, at 4:11 AM, Brett Cannon wrote:
That all sounds reasonable (and the reason I think it is a good idea), but convincing python-dev in general might be tough. Especially since that would cause IDLE to not be part of the stdlib.
I've no hope of convincing python-dev myself; the response to my suggestion about moving email out was... disappointing. I just don't have the time needed to champion any large changes these days, and a "Lean Python" is a hard sell.
It is definitely a hard sell. There is a reason this is the third time I am trying to reorganize everything. =) I think the "batteries included" philosophy is too heavily ingrained in the community to ever let us take large strides towards being more like Perl. Getting rid of anything is going to require that it be obsolete or so externally tied to something that it is just more practical to move it out. Otherwise the chances of taking something out (e.g., email) is going to be damn near impossible.
I think that essential things like the email package should be part of the standard library.
Non-essential things like e.g. the tk package or the audio/image/etc. libs can well be separated out into stand-alone packages.
They may still be supported and maintained by the PSF, but getting them would require an extra install step.
I actually think that this would benefit the stand-alone packages: mostly because they would no longer be tied to the Python release cycle, rather strict development scheme and strong focus on certain aspects of Python's application space.
In any case, I agree that putting energy into such an effort is better spent elsewhere.
On Feb 24, 2008, at 4:58 PM, M.-A. Lemburg wrote:
I think that essential things like the email package should be part of the standard library.
Non-essential things like e.g. the tk package or the audio/image/etc. libs can well be separated out into stand-alone packages.
What's essential is a judgement call. You & I would draw the line in different places.
Things that are tightly coupled with the Python runtime do seem to belong in the standard library. A feature that I hear requests for frequently that would be tightly coupled would be deferred imports.
They may still be supported and maintained by the PSF, but getting them would require an extra install step.
I think supported & maintained by the PSF is fine; I'm not in favor of throwing out useful packages.
In any case, I agree that putting energy into such an effort is better spent elsewhere.
Interestingly, I didn't see either myself or Brett say anything like this. I only said I don't have the time to champion such an idea, not that I had anything else to do (there's work, there's family, and then... I'm wiped out).
-Fred
On 2008-02-24 23:39, Fred Drake wrote:
On Feb 24, 2008, at 4:58 PM, M.-A. Lemburg wrote:
I think that essential things like the email package should be part of the standard library.
Non-essential things like e.g. the tk package or the audio/image/etc. libs can well be separated out into stand-alone packages.
What's essential is a judgement call. You & I would draw the line in different places.
Right, and that's what causes endless discussions.
Things that are tightly coupled with the Python runtime do seem to belong in the standard library. A feature that I hear requests for frequently that would be tightly coupled would be deferred imports.
Then we have a different idea of scope of the std lib. We'd have to remove the tk package, the html package, the dbm package, etc. if we were to follow your idea of what the std lib should be and only very few modules would be left in such a std lib.
Other languages split such modules into a "core" or "lang" package. Perhaps that's what you're after ?
They may still be supported and maintained by the PSF, but getting them would require an extra install step.
I think supported & maintained by the PSF is fine; I'm not in favor of throwing out useful packages.
In any case, I agree that putting energy into such an effort is better spent elsewhere.
Interestingly, I didn't see either myself or Brett say anything like this. I only said I don't have the time to champion such an idea, not that I had anything else to do (there's work, there's family, and then... I'm wiped out).
That's essentially what I meant.
On 24/02/2008, Brett Cannon brett@python.org wrote:
And that would make the standard library smaller, and easier to maintain. Always a good thing.
That all sounds reasonable (and the reason I think it is a good idea), but convincing python-dev in general might be tough. Especially since that would cause IDLE to not be part of the stdlib.
I've no real opinion myself, but I believe one of the sticking points is that without tk, there's no way in core Python of putting up a simple GUI. The pydoc server installed with Windows Python ("Module Docs" on the start menu) and the Twisted installer use this, I believe.
Paul.
Le lundi 25 février 2008 à 12:47 +0000, Paul Moore a écrit :
I've no real opinion myself, but I believe one of the sticking points is that without tk, there's no way in core Python of putting up a simple GUI. The pydoc server installed with Windows Python ("Module Docs" on the start menu) and the Twisted installer use this, I believe.
Hmm, each time I've installed Twisted, it was just "python setup.py install".
participants (5)
-
Antoine Pitrou -
Brett Cannon -
Fred Drake -
M.-A. Lemburg -
Paul Moore